Python developers are embracing type hints

https://pyrefly.org/blog/why-typed-python/

by ocamoss • 10 months ago

318 566 10 months ago

LoganDark• 10 months ago

I think I've always used Python type hints, but that was partially because early versions of Discord.py relied on them (maybe it still does). But it was also because I like to be able to mentally verify my code's correctness before running it, and waiting for runtime errors is comparatively a huge waste of time (in my opinion).

secondcoming• 10 months ago

I recently had to debug someone else's Python code and trying to figure out what variables are was a massive headache, especially coming from C++.

skydhash2• 10 months ago

I do not program that much in python, but I believe the general accepted wisdom in dynamic languages was explicit name and load of documentations (as comments and docstrings).

imron4• 10 months ago

Absolutely the general accepted wisdom in line with best practices - that are often ignored

maleldil4• 10 months ago

explicit name and load of documentations (as comments and docstrings).

Which can be out of date are often missing. Might as well use type-hints that can be statically checked.

Akronymus• 10 months ago

Even c++ feels clunky in terms of types to me. Though that's probably down to me preferring a more complete type system like haskell has

rcfox• 10 months ago

In Python, every variable is either defined or imported in the file in which it's used, so you always know where to find it. (Assuming you don't do `from foo import *`, which is frowned upon.)

In C++, a variable might be defined in a header or in a parent class somewhere else, and there's no indication of where it came from.

maleldil4• 10 months ago

How does this help when trying to determine the parameters a function takes? You have to either hope that the name is descriptive enough or that the function is well-documented. Failing that, you need to read the code to find out.

kstenerud2• 10 months ago

CMD-click shows you.

lacker• 10 months ago

Type hints are much easier to use nowadays than they were a few years ago, because the agentic tools like Claude Code are very good at converting an existing codebase to using type hints.

OutOfHere• 10 months ago

The flip side of it is that Claude Code will have a very bad time in a code base with grossly unsatisfiable or conflicting types (where a type checker would fail the project). A human should always first ensure that the types are broadly correct, with or without the assistance of code tools.

Waterluvian2• 10 months ago

I can empathize with the code tools. Sometimes I’ll read Python code and have no idea at first glance if these are type bugs or creative coding by the dev. Python is incredibly flexible. Though I think most of the time you really shouldn’t be using the flexibility.

imron4• 10 months ago

I enforce strong types on all Python code I’m responsible for - and make sure others don’t play fast and loose with dict[str, Any] when they could use a well defined type.

Doing otherwise is just asking for prod incidents.

scuff3d16• 10 months ago

I worked on a project that did this. Drove me absolutely nuts. It's like having all the worst parts of a dynamic language and a static language with none of the benefits.

I'd much rather just work in a statically typed language from the start.

lrobinovitch• 10 months ago

What exactly drove you nuts? The python ecosystem is very broad and useful, so it might be suitable for the application (if not, reasonable that you'd be frustrated). With strict mypy/pyright settings and an internal type-everything culture, Python feels statically typed IME.

imron4• 10 months ago

I too would much rather work in a statically typed language, but sometimes you have to work with what you’ve got.

These systems are part of the core banking platform for a bank so I’d rather some initial developer friction over runtime incidents.

And I say initial friction because although developers are sometimes resistant to it initially, I’ve yet to meet one who doesn’t come to appreciate the benefits over the course of working on our system.

Different projects have different requirements, so YMMV but for the ones I’m working on type hints are an essential part of ensuring system reliability.

budro• 10 months ago

Type hints seem fantastic for when you're in maintenance mode and want to add sanity back to a system via automated tooling.

However for new projects I find that I'd much rather pick technologies that start me off with a sanity floor which is higher than Python's sanity ceiling. At this point I don't want to touch a dynamically typed language ever again.

minikomi• 10 months ago

Always fun to inherit a data-scientist derrived chunk of pytjon code for which every type hint is 'takes a dataframe' and 'returns a dataframe'..

Waterluvian2• 10 months ago

Typescript turned me into a believer but my gosh do python typings feel clumsy and quickly busy up files. I get why, and it’s not exactly realistic, but I wish a lot of it didn’t require an import.

Whatever the solution is, it doesn’t include giving up on Python typings.

mrln• 10 months ago

With the newest Python versions, most of the time I don't need typing imports!

letmeinhere4• 10 months ago

Yeah post 3.10 you don't need Union, Optional, List, Duct, Tuple. Any still necessary when you want to be permissive, and I'm still hoping for an Unknown someday...

quotemstr• 10 months ago

Type hints in dynamic languages are great, but I wish they came with deeper integration into the language runtime for validation and for optimizer setup.

If I have a function that takes an int, and I write down the requirement, why should a JIT have to learn independently of what I wrote down that the input is an int?

I get that it's this way because of how these languages evolved, but it doesn't have to stay this way.

dmurray• 10 months ago

That was the original intent of mypy, to allow a subset of Python to be interpreted by a JIT or transpiled to a compiled, statically typed language.

The type hints proved to be useful on their own so the project moved past what was useful for that purpose, but a new JIT (such as the one the upcoming CPython 3.14 lays the groundwork for) could certainly use them.

donatj• 10 months ago

Typings have pretty cleanly been getting added to PHP over the last decade. I'm kind of surprised Python's are so bolted on by comparison

morkalork• 10 months ago

They do remove an entire class of avoidable errors in code bases of course people will embrace it.

LordDragonfang• 10 months ago

The biggest reason I use typehints is that VSCode's intellisense relies on them - and I know I've missed one when typing a dot doesn't give me the method I'm expecting.

circadian2• 10 months ago

I really love Python for it's expedience, but type hints still feel like they don't belong in the language. They don't seem to come with the benefits of optimisation that you get with static typed languages. As someone who uses C and Julia (and wishes they had time for Rust), introducing solid typing yields better end results at a minimum, or is a requirement at the other end of the scale.

The extra typing clarification in python makes the code harder to read. I liked python because it was easy to do something quickly and without that cognitive overhead. Type hints, and they feel like they're just hints, don't yield enough of a benefit for me to really embrace them yet.

Perhaps that's just because I don't use advanced features of IDEs. But then I am getting old :P

EDIT: also, this massively depends on what you're doing with the language! I don't have huge customer workloads to consider any longer..!

imron4• 10 months ago

I don't use advanced features of IDEs

I use vanilla vim (no plugins) for my editor, and still consider type hints essential.

zahlman8• 10 months ago

They don't seem to come with the benefits of optimisation that you get with static typed languages

They don't. And cannot, for compatibility reasons. Aside from setting some dunders on certain objects (which are entirely irrelevant unless you're doing some crazy metaprogramming thing), type annotations have no effect on the code at runtime. The Python runtime will happily bytecode-compile and execute code with incorrect type annotations, and a type-checking tool really can't do anything to prevent that.

afiori4• 10 months ago

Now that python has a jit it could use them (not saying it should) for speculative compilation

My understanding is that currently python can collect type data in test runs and use it to inform the jit during following executions

xdfgh1112• 10 months ago

They catch bugs. And you don't have to use them; even if they're only provided by libraries, there is a benefit to users.

stellalo• 10 months ago

The extra typing clarification in python makes the code harder to read

It’s funny, because for me is quite the opposite: I find myself reading Python more easily when there are type annotations.

One caveat might be: for that to happen, I need to know that type checking is also in place, or else my brain dismissed annotations in that they could just be noise.

I guess this is why in Julia or Rust or C you have this stronger feeling that types are looking after you.

circadian2• 10 months ago

I think the face they fundamentally don't look after you is where my resistance comes from. Will try and evaluate some newer code that uses them and see how I get on a bit more :)

Ekaros2• 10 months ago

Remembering project where type hints would have been helpful to grok the code I do now mostly like them. They are useful when you come back after days or weeks and try to remember what does this function produce and what does this one actually take in.

And Python always was rather strongly typed, so you anyway had to consider the types. Now you get notes. Which often do help.

IshKebab8• 10 months ago

The extra typing clarification in python makes the code harder to read.

It depends what you mean by "read". If you literally mean you're doing a weird Python poetry night then sure they're sort of "extra stuff" that gets in the way of your reading of `fib`.

But most people think of "reading code" and reading and understanding code, and in that case they definitely make it easier.

tdeck5• 10 months ago

    'Twas brillig: Adjective and the slithy toves: Noun
    Did gyre: Verb and gimble: Verb in the wabe: Noun

Izkata2• 10 months ago

As someone who has read code as easily as English for decades (which is apparently rare, if my co-workers are any indication), too many type annotations clutter it up and make it a lot harder to read. And this is after having used Typescript a lot in the past year and liking that system - it works well because so much can be inferred.

mcdeltat• 10 months ago

Interesting that for you typing makes the code harder to read. What context do you use Python for? And who is writing it?

In my experience I have seen far too much Python code like

`def func(data, args, *kwargs)`

with no documentation and I have no clue wtf it's doing. Now I am basically all in on type hints (except cases where it's impossible like pandas).

bgwalter4• 10 months ago

Because they follow any corporate initiative that gives them something to do, even if the type hints are the most unreadable and hackish form of typing in existence.

scuff3d16• 10 months ago

Or you could just use a statically typed language and get a much better experience.

fnord77• 10 months ago

A entire class of bugs, wiped out by a thing called a "compiler". Gigahours of downtime and bug fixing globally prevented by a modest extra step up front. Great stuff.

scuff3d16• 10 months ago

I had someone say to me they preferred strict type checking in a Python linter over a statically typed language because they "don't like a build step"...

Dudes it's literally just worse compilation with extra steps.

ashu14613• 10 months ago

Sometimes that is not an option, consider the bias which python gets due to all the LLM libraries being python first.

krzat• 10 months ago

Yeah, I thought lack of typing in python was intentional to support this another paradigm of programming for geniuses who don't need hand holding.

Turns out they just didn't know any better?

scuff3d16• 10 months ago

How would a static type system have anything to do with handholding?

chpatrick13• 10 months ago

Would you? Why?

Python has a great experience for a bunch of tasks and with typing you get the developer experience and reliability as well.

pansa211• 10 months ago

Why?

Python’s 3 traditional weak spots, which almost all statically-typed languages do better: performance, parallelism and deployment.

scuff3d16• 10 months ago

No you don't. You get the illusion of static types without the actual upsides.

For any even medium sized project or anything where you work with other developers a statically typed language is always going to be better. We slapped a bunch of crap on Python to make it tolerable, but nothing more.

throwaway815232• 10 months ago

Oh datatype hints. I ignored the headline on first scan, thinking it was about font metrics.

simonw4• 10 months ago

The thing that finally got me on board with optional type hints in Python was realizing that they're mainly valuable as documentation.

But it's really valuable documentation! Knowing what types are expected and returned just by looking at a function signature is super useful.

lysace• 10 months ago

Decent argument in principle. It still sucks for non-obvious types though:

https://old.reddit.com/r/Python/comments/10zdidm/why_type_hi...

Edit: Yes, one can sometimes go with Any, depending on the linter setup, but that's missing the point, isn't it?

mjr009• 10 months ago

As the top comment says, if you don't know or want to define the type just use Any. That's what it's there for.

That entire Reddit post is a clueless expert beginner rant about something they don't really understand, unfortunate that it's survived as long as it has or that anyone is taking it as any sort of authoritative argument just because it's long.

drekipus• 10 months ago

The correct response to this is to figure what is the use case for your function: IE: add two numbers. Set the input and output as decimal and call it a day

kstenerud2• 10 months ago

Actually, it's not missing the point. Sometimes you really do want duck typing, in which case you allow Any. It's not all-or-nothing.

What the reddit post is demonstrating is that the Python type system is still too naive in many respects (and that there are implementation divergences in behavior). In other languages, this is a solved problem - and very ergonomic and safe.

smilliken• 10 months ago

The best kind of documentation is the kind you can trust is accurate. Type defs wouldn't be close to as useful if you didn't really trust them. Similarly, doctests are some of the most useful documentation because you can be sure they are accurate.

zbentley3• 10 months ago

The best docs are the ones you can trust are accurate. The second best docs are ones that you can programmatically validate. The worst docs are the ones that can’t be validated without lots of specialized effort.

Python’s type hints are in the second category.

ninetyninenine17• 10 months ago

This is a naive realization. When type checking is used to the maximum extent they become as just as important as unit testing. It is an actual safety contribution to the code.

Many old school python developers don't realize how important typing actually is. It's not just documentation. It can actually roughly reduce dev time by 50% and increase safety by roughly 2x.

MangoToupe3• 10 months ago

Static type checking (which is what I assume you mean by "typing") can also be a massive pain in the ass that stands in the way of incremental development, even if the end-goal is to ship an api with clear type signatures.

There are developers who design apis by trying to figure out readable invocations. These developers discover, rather than design, type hierarchies and library interfaces.

Many old school python developers don't realize how important typing actually is.

I don't think this is true. There's simply a communication breakdown where type-first developers don't see the benefits of disabling static checking to design interfaces, and interface-first developers don't see why they should put static checking ahead of interface iteration speed.

simonw4• 10 months ago

It's claims like that which used to put me off embracing type hints!

I'd been programming for 20+ years and I genuinely couldn't think of any situations where I'd had a non-trivial bug that I could have avoided if I'd had a type checker - claims like "reduce dev time by 50%" didn't feel credible to me, so I stuck with my previous development habits.

Those habits involved a lot of work performed interactively first - using the Python terminal, Jupyter notebooks, the Firefox/Chrome developer tools console. Maybe that's why I never felt like types were saving me any time (and in fact were slowing me down).

Then I had my "they're just interactive documentation" realization and finally they started to click for me.

JimDabell4• 10 months ago

It can actually roughly reduce dev time by 50% and increase safety by roughly 2x.

Type annotations don’t double productivity. What does “increase safety by 2×” even mean? What metric are you tracking there?

In my experience, the main non-documentation benefit of type annotations is warning where the code is assuming a value where None might be present. Mixing up any other kind of types is an extremely rare scenario, but NoneType gets everywhere if you let it.

lelanthran6• 10 months ago

The thing that finally got me on board with optional type hints in Python was realizing that they're mainly valuable as documentation.
But it's really valuable documentation! Knowing what types are expected and returned just by looking at a function signature is super useful.

So ... you didn't have this realisation prior to using Python type hints? Not from any other language you used prior to Python?

simonw4• 10 months ago

I didn't. I've been mainly a Python, PHP and JavaScript programmer for ~25 years and my experience with typed languages was mostly pre-type-inference Java which felt wildly less productive than my main languages.

__MatrixMan__5• 10 months ago

Type hints as documentation are a gateway drug to type hints for bug finding. Keep at it :)

Syntaf2• 10 months ago

This resonates with me this so much. I feel like half the comments in this thread are missing the value typing, but maybe they've never had the misfortune of working with hundreds of other developers on a project with no defined contracts on aggregates / value objects outside of code comments and wishful thinking.

I've worked on large python codebases for large companies for the last ~6 years of my career; types have been the single biggest boon to developer productivity and error reduction on these codebases.

Just having to THINK about types eliminates so many opportunities for errors, and if your type is too complex to express it's _usually_ a code smell; most often these situations can be re-written in a more sane albeit slightly verbose fashion, rather than using the more "custom" typing features.

No one gets points for writing "magical" code in large organizations, and typing makes sure of this. There's absolutely nothing wrong with writing "boring" python.

Could we have accomplished this by simply having used a different language from the beginning? Absolutely, but often times that's not a option for a company with a mature stack.

TL;DR -- Typing in python is an exception tool to scale your engineering organization on a code-base.

tecoholic• 10 months ago

I love typing in Python. I learnt programming with C++ and OOPs. It was freeing when I took up Python to note care about types, but I have come to enjoy types as I got older.

But, boy have we gone overboard with this now? The modern libraries seem to be creating types for the sake of them. I am drowning in nested types that seem to never reach native types. The pain is code examples of the libraries don’t even show them.

Like copy paste an OpenAI example and see if LSP is happy for example. Now I have gotten in this situation where I am mentally avoiding type errors of some libraries and edging into wishing Pydantic et al never happened.

AlienRobot4• 10 months ago

My love for python was critically hurt when I learned about typing.TYPE_CHECKING.

For those unaware, due to the dynamic nature of Python, you declare a variable type like this

    foo: Type

This might look like Typescript, but it isn't because "Type" is actually an object. In python classes and functions are first-class objects that you can pass around and assign to variables.

The obvious problem of this is that you can only use as a type an object that in "normal python" would be available in the scope of that line, which means that you can't do this:

    def foo() -> Bar:
        return Bar()
    
    class Bar:
        pass

Because "Bar" is defined AFTER foo() it isn't in the scope when foo() is declared. To get around this you use this weird string-like syntax:

    def foo() -> "Bar":
        return Bar()

This already looks ugly enough that should make Pythonists ask "Python... what are you doing?" but it gets worse.

If you have a cyclic reference between two files, something that works out of the box in statically typed languages like Java, and that works in Python when you aren't using type hints because every object is the same "type" until it quacks like a duck, that isn't going to work if you try to use type hints in python because you're going to end up with a cyclic import. More specifically, you don't need cyclic imports in Python normally because you don't need the types, but you HAVE to import the types to add type hints, which introduces cyclic imports JUST to add type hints. To get around this, the solution is to use this monstrosity:

    if typing.TYPE_CHECKING:
        import Foo from foo

And that's code that only "runs" when the static type check is statically checking the types.

Nobody wants Python 4 but this was such an incredibly convoluted way to add this feature, specially when you consider that it means every module now "over-imports" just to add type hints that they previously didn't have to.

Every time I see it makes me think that if type checks are so important maybe we shouldn't be programming Python to begin with.

dandiep• 10 months ago

Isn’t this solved in 3.14/PEP-649?

zahlman8• 10 months ago

that isn't going to work if you try to use type hints in python because you're going to end up with a cyclic import. More specifically, you don't need cyclic imports in Python normally because you don't need the types, but you HAVE to import the types to add type hints, which introduces cyclic imports JUST to add type hints.

Yes, `typing.TYPE_CHECKING` is there so that you can conditionally avoid imports that are only needed for type annotations. And yes, importing modules can have side effects and performance implications. And yes, I agree it's ugly as sin.

But Python does in fact allow for cyclic imports — as long as you're importing the modules themselves, rather than importing names `from` those modules. (By the way, the syntax is the other way around: `from ... import ...`.)

https://stackoverflow.com/questions/744373/

ninetyninenine17• 10 months ago

You're actually missing the benefit of this. It's actually a feature.

With python, because types are part of python itself, they can thus be programmable. You can create a function that takes in a typehint and returns a new typehint. This is legal python. For example below I create a function that dynamically returns a type that restricts a Dictionary to have a specific key and value.

   from typing import TypedDict

   def make_typed_dict(name: str, required_key: str, value_type: type):
       return TypedDict(name, {required_key: value_type, id: int})

   # Example
   UserDict = make_typed_dict("UserDict", "username", str)

   def foo(data: UserDict):
       print(data["username"])

With this power in theory you can create programs where types essentially can "prove" your program correct, and in theory eliminate unit tests. Languages like idris specialize in this. But it's not just rare/specialized languages that do this. Typescript, believe it or not, has programmable types that are so powerful that writing functions that return types like the one above are Actually VERY common place. I was a bit late to the game to typescript but I was shocked to see that it was taking cutting edge stuff from the typing world and making it popular among users.

In practice, using types to prove programs to be valid in place of testing is actually a bit too tedious compared with tests so people don't go overboard with it. It is a much more safer route then testing, but much harder. Additionally as of now, the thing with python is that it really depends on how powerful the typechecker is on whether or not it can enforce and execute type level functions. It's certainly possible, it's just nobody has done it yet.

I'd go further than this actually. Python is actually a potentially more powerfully typed language than TS. In TS, types are basically another language tacked onto javascript. Both languages are totally different and the typing language is very very limited.

The thing with python is that the types and the language ARE the SAME thing. They live in the same universe. You complained about this, but there's a lot of power in that because basically types become turing complete and you can create a type that does anything including proving your whole program correct.

Like I said that power depends on the typechecker. Someone needs to create a typechecker that can recognize type level functions and so far it hasn't happened yet. But if you want to play with a language that does this, I believe that language is Idris.

meander_water2• 10 months ago

There's actually another issue with ForwardRefs. They don't work in the REPL. So this will work when run as a module:

  def foo() -> "Bar":
     return Bar()

But will throw an error if copy pasted into a REPL.

However, all of these issues should be fixed in 3.14 with PEP649 and PEP749:

At compile time, if the definition of an object includes annotations, the Python compiler will write the expressions computing the annotations into its own function. When run, the function will return the annotations dict. The Python compiler then stores a reference to this function in __annotate__ on the object.
This mechanism delays the evaluation of annotations expressions until the annotations are examined, which solves many circular reference problems.

Too4• 10 months ago

This is trivial to solve by simply not having circular imports. Place the types in one file and the usage of it in others.

This has many benefits, like forcing you to think about the dependencies and layers of your architecture. Here is a good read about why, from F# that has the same limitation https://fsharpforfunandprofit.com/posts/cyclic-dependencies/

As others already mentioned, importing __annotations__ also works.

alfons_foobar3• 10 months ago

Agreed that this "hack" is very ugly!

On the other hand, I tend to take it as a hint that I should look at my module structure, and see if I can avoid the cyclic import (even if before adding type hints there was no error, there still already was a "semantic dependency"...)

JackSlateur3• 10 months ago

from __future__ import annotations

actinium226• 10 months ago

If you have a cyclic reference between two files,

Don't have cyclic references between two files.

It makes testing very difficult, because in order to test something in one file, you need to import the other one, even though it has nothing to do with the test.

It makes the code more difficult to read, because you're importing these two files in places where you only need one of them, and it's not immediately clear why you're importing the second one. And it's not very satisfying to learn that you you're importing the second one not because you "need" it but because the circular import forces you to do so.

Every single time you have cyclic references, what you really have are two pieces of code that rely on a third piece of code, so take that third piece, separate it out, and have the first two pieces of code depend on the third piece.

Now things can be tested, imports can be made sanely, and life is much better.

pton_xd• 10 months ago

But, boy have we gone overboard with this now? The modern libraries seem to be creating types for the sake of them. I am drowning in nested types that seem to never reach native types.

Thought you were talking about TypeScript for a moment there.

afiori4• 10 months ago

Except that typescript structural typing and features make it much easier to swim.

Also python is far less aggressive with lint warnings so it is much easier to make mistakes

ninetyninenine17• 10 months ago

I learned C++ before learning python as well and python felt like a breath of fresh air.

At first I thought it was because of the lack of types. But in actuality the lack of types was a detriment for python. It was an illusion. The reason why python felt so much better was because it had clear error messages and a clear path to find errors and bugs.

In C++ memory leaks and seg faults are always hidden from view so EVEN though C++ is statically typed, it's actually practically less safe then python and much more harder to debug.

The whole python and ruby thing exploding in popularity back in the day was a trick. It was an illusion. We didn't like it more because of the lack of typing. These languages were embraced because they weren't C or C++.

It took a decade for people to realize this with type hints and typescript. This was a huge technical debate and now all those people were against types are proven utterly wrong.

raincole• 10 months ago

It was an illusion. We didn't like it more because of the lack of typing. These languages were embraced because they weren't C or C++.

It's an illusion only you once had. Java (a language that is not C or C++) got mainstream way before Python.

_zoltan_• 10 months ago

modern C++ is great, to be honest.

biimugan• 10 months ago

In addition to what others have mentioned, it also just makes it easier to come back later to a code base and make changes, especially refactoring. In many cases you don't even really have to add many type hints to get benefits from it, since many popular libraries are more-or-less already well-typed. It can also substitute for many kinds of unit tests that you would end up writing even 5 years ago. If you're an infrastructure engineer or data scientist that's usually just writing a lot of glue code, then it greatly helps speed up your output (I've found)

ashu14613• 10 months ago

This

Without typing it is literally 100x harder to refactor your code, types are like a contract which if are maintained after the refactor gives you confidence. Over time it leads to faster development

frou_dh• 10 months ago

Because you almost always have a specific type in mind for that function parameter, so you might as well just write it down.

iandanforth• 10 months ago

I hate typing in Python. I spend a good chunk of my day fighting the type checker and adding meaningless assertions, casts, and new types all to satisfy what feels like an obsessive compulsive nitpicker. "Type partially unknown" haunts my dreams.

Duck typing is one of the best things about Python. It provides a developer experience second to none. Need to iterate over a collection of things? Great! Just do it! As long as it is an iterable (defined by methods, not by type) you can use it anywhere you want to. Want to create a data object that maps any hashable type to just about anything else? Dict has you covered! Put anything you want in there and don't worry about it.

If we ended up with a largely bug free production system then it might be worth it, but, just like other truly strongly typed languages, that doesn't happen, so I've sacrificed my developer experience for an unfulfilled promise.

If I wanted to use a strongly typed language I would, I don't, and the creeping infection of type enforcement into production codebases makes it hard to use the language I love professionally.

maleldil4• 10 months ago

Need to iterate over a collection of things?

Iterable[T]

Want to create a data object that maps any hashable type to just about anything else?

Mapping[T, U]

dwattttt• 10 months ago

Beyond the advantage that a type-checker/linter can tell if you're doing the right thing when writing those functions, it lets an IDE infer what type you're iterating over, in order to provide more support/completion/hinting/checks (without recursively analyzing arbitrary code, so: 'instantly' vs 'maybe not ever).

jgb19842• 10 months ago

Couldn't agree more! I've been using Python for almost 20 years, my whole career is built on it, and I never missed typing. Code with type hints is so verbose and unpythonic, making it much harder to read. Quite an annoying evolution.

pansa211• 10 months ago

As the article says, type hints represent a fundamental change in the way Python is written. Most developers seem to prefer this new approach (especially those who’d rather be writing Java, but are stuck using Python because of its libraries).

However it is indeed annoying for those of us who liked writing Python 2.x-style dynamically-typed executable pseudocode. The community is now actively opposed to writing that style of code.

I don’t know if there’s another language community that’s more accepting of Python 2.x-style code? Maybe Ruby, or Lua?

dragonwriter12• 10 months ago

Duck typing is one of the best things about Python.

And duck typing with the expected contract made explicit and subject to static verification (and IDE hinting, etc.) is one of the best things about Python typing.

If we ended up with a largely bug free production system then it might be worth it, but, just like other truly strongly typed languages, that doesn't happen

I find I end up at any given level of bug freeness with less effort and time with Python-with-types than Python-without-types (but I also like that typing being optional means that its very easy to toss out exploratory code before settling on how something new should work.)

rkomorn• 10 months ago

I find I end up at any given level of bug freeness with less effort and time with Python-with-types than Python-without-types

Same.

Type hints also basically give me a "don't even bother running this if my IDE shows type warnings" habit that speeds up python development.

Absence of warnings doesn't guarantee me bug-free code but presence of warnings pretty much guarantees me buggy code.

Type hints are a cheap way to reduce (not eliminate) run time problems.

jmward01• 10 months ago

Type hints in python are just that, hints. Use them to help with clarity but enforcing them and requiring them everywhere generally leads to the worst of all worlds. Lots of boilerplate, less readable code and throwing away many of the features that make python powerful. Use the best language for the job and use the right language features at the right time. I see too many black or white arguments in the developer community, there is a middle ground and the best code is almost always written there.

IshKebab8• 10 months ago

Use the best language for the job

Sometimes you don't have a choice though, and other people have picked Python despite it rarely being the best language for any job.

In that case it's nice to be able to use static type hints and benefit from improved readability, productivity and reliability.

dragonwriter12• 10 months ago

Lots of boilerplate, less readable code and throwing away many of the features that make python powerful.

IMO, that complaint almost always goes with overuse of concrete types when abstract (Protocol/ABC) types are more accurate to the function of the code.

There was a time that that was a limitation in Python typing, but that that hasn’t been true for almost as long as Python typing had been available at all before it stopped being true.

zahlman8• 10 months ago

It's the other way around, IMO: people who think the language should at least have type hints are now more willing to use it, now that there's better tooling for checking those hints.

pansa211• 10 months ago

Yes. And people who preferred the language (and its culture) before the "fundamental change" of adding type hints are now less willing to use it.

zahlman8• 10 months ago

Probably some people are. I just mostly don't think about the annotations.

k3vinw• 10 months ago

I really think that Rust has one of the best designed/inspired type systems.

If I had to rewrite a Python project, I would consider Rust or another statically typed language before choosing to continue in a dynamic language with types bolted on. I hope the situation improves for dynamic languages with optional types, but it still feels weird and bolted onto the language because it is.

hirvi742• 10 months ago

or another statically typed language

I'm a professional .Net Core developer, but I'd throw my hat in the ring for Swift on this one. While obviously not exactly a 1:1 with Rust, there is definitely some common benefits between the two. Though, from what I understand of Rust (very little), its typing system is slightly more strict than Swift's which is slightly more strict than C#'s.

yeasku• 10 months ago

I am suspicius of every codder who does not appreciate types.

a_t48• 10 months ago

Has anyone had good luck with auto-annotation of types of existing codebases? Either via LLM or via various runtime hooks? I work in a codebase that started off in Python 2 and isn't annotated with types in the majority of places, and I feel the pain every time I have to wonder what exactly the arguments to a method is.

EdwardDiego3• 10 months ago

Yep, I've used this pretty successfully, the ideal is to run it under realistic prod traffic over time to capture as many types as can flow into a given function, but a good set of unit/integration tests can also provide good coverage.

And if you re-use the same type store (SQLite DB) across multiple instrumented runs, you can further improve it.

https://github.com/Instagram/MonkeyType

emeryberger• 10 months ago

RightTyper is much better in addition to running orders of magnitude faster.

https://github.com/RightTyper/RightTyper

(full disclosure, I am one of its authors).

dandanua2• 10 months ago

This is why I think Julia will win in the long run. It has an amazing type system, simple yet powerful. In particular, abstract types are much easier to define and use than abstract classes in Python.

jakobnissen2• 10 months ago

Ooh, I completely disagree. Julia has a worse type system overall, IMO. The big downside of Julia is that Julia has no interfaces or protocols. So, you can't type assert that something is an iterable of integers, for example.

Another issue is that abstract types are completely undocumented and have no tooling support. You say it's easier to use an abstract type. Can you tell me what I need to define to create a working subtype of AbstractDict? Or Number? Or IO? It's completely undefined, and the only way to do it is to just define the type and then try it out and patch when it breaks because a method was missing.

Finally, there is no multiple inheritance. That means I can't define something which is both a subtype of AbstractArray and IO, for example.

dandanua2• 10 months ago

There are no traits in Julia by default, that's true. But since types are first class citizens in Julia, traits can be implemented within the language. There is a package SimpleTraits.jl that implements Holy's trait trick, see also this tutorial https://ahsmart.com/pub/holy-traits-design-patterns-and-best...

An ability to work with types within the language is already a win for me.

ashu14613• 10 months ago

A huge supporter of typing in python, but have observed that type sense which pycharm provides out of the box has its fair share of bugs as well.

Also should check out ty by astral, it is pretty fast and does a good job at typechecking.

https://docs.astral.sh/ty/editors/

teiferer• 10 months ago

Misleading title. I was expecting to read about why devs actually embrace type hints. What the article is about is why you should and how you can use type hints. That's valuable, but different from what the title suggests.

Besides, the lack of static typic is what makes a lot of the appeal for beginners. It's much harder to convince a non-CS beginner why they should bother with the extra burden of type hits. They are optional anyway and just slow folks down (so they might think). Careful with generally demanding that everybody use them.

But they probably help coding assistants to make fewer mistakes, so maybe that will soon be an argument if it isn't already. (That's an angle I expected in the article.)

ambyra• 10 months ago

With duck typing, you don’t need type hints. You’re just supposed to use the variable however you “feel” it should be used when you’re using it, and it automagically just works!!! Try it! /s

Havoc• 10 months ago

It’s ok. The mild ground of typing feels pretty clunky to me though

Definitely not a best of both world type outcome

lukaslalinsky2• 10 months ago

I was extremely skeptical when typing was introduced. What's the point if runtime ignores them. I forced myself to use them as documentation and now I'm on the other side of the spectrum, all code should have them. It already helped me a lot during refactors and I always wished more code had types. I think the same is true for AIs, they will benefit from having the types explicitly said. It's a shame they currently default to untyped Python.

JodieBenitez• 10 months ago

What's the point if runtime ignores them.

I've been using this sparingly: https://pypi.org/project/type-enforced/

dragonwriter12• 10 months ago

What's the point if runtime ignores them.

Ideally, with static checking, the runtime shouldnn’t need to care about types because cide that typechecks shouldn’t be capable of not behaving according to the types declared.

Python, even with the most restrictive settings in nost typecheckers, may not quite achieve that, but it certainly reeuces the chance of surprises lf that kind compared to typing information in docstrings, or just locked away in the unststed assumptions of some developer.

lukaslalinsky2• 10 months ago

The thing is, when typing was being discussed, I was hoping it would lead to JavaScript-like evolution, where the dynamic nature of Python could be restricted if I use the right types, and a JIT compiler could optimize parts of the code, expecting u32 ints instead of PyObjects.

fithisux• 10 months ago

I started using Python at work with type hints. I am very satisfied.

zoom6628• 10 months ago

Boring old me would be reaching for mojo in order to have types that actually are "real" rather than just an editing overlay of decorators/DSL/tooling.

Too4• 10 months ago

Too bad Mojo gave up on Python compatibility on code level. Now it’s just one of a dozen “Python inspired” languages, with the only benefit that they aim for easily calling into other Python code.

defraudbah• 10 months ago

Python developers are embracing RuntimeError.. It's amazing language that had it place, now it's time to sunset it and forget it. Leave it to prototyping only

seanparsons4• 10 months ago

As a static typing advocate I do find it funny how all the popular dynamic languages have slowly become statically typed. After decades of people saying it's not at all necessary and being so critical of statically typed languages.

When I was working on a fairly large TypeScript project it became the norm for dependencies to have type definitions in a relatively short space of time.

adalacelove2• 10 months ago

People adapt to the circumstances. A lot of Python uses are no longer about fast iteration on the REPL. Instead of that we are shipping Python to execute in clusters on very long running jobs or inside servers. It's not only about having to start all over after hours, it's simply that concurrent and distributed execution environments are hostile to interactive programming. Now you can't afford to wait for an exception and launch the debugger in postmortem. Or even if you do it's not very useful.

And now my personal opinion: If we are going the static typing way I would prefer simply to use Scala or similar instead of Python with types. Unfortunately in the same way that high performance languages like C attracts premature optimizers static types attract premature "abstracters" (C++ both). I also think that dynamic languages have the largest libraries for technical merit reasons. Being more "fluid" make them easier to mix. In the long term the ecosystem converges organically on certain interfaces between libraries.

And so here we are with the half baked approach of gradual typing and #type: ignore everywhere.

yurishimo• 10 months ago

PHP is a great example of the convergence of interfaces. Now they have different “PSR” standards for all sorts of things. There is one for HTTP clients, formatting, cache interfaces, etc. As long as your library implements the spec, it will work with everything else and then library authors are free to experiment on the implementation and contribute huge changes to the entire ecosystem when they find a performance breakthrough.

Types seem like a “feature” of mature software. You don’t need to use them all the time, but for the people stuck on legacy systems, having the type system as a tool in their belt can help to reduce business complexity and risk as the platform continues to age because tooling can be built to assert and test code with fewer external dependencies.

pydry3• 10 months ago

Here we are because:

* Types are expensive and dont tend to pay off on spikey/experimental/MVP code, most of which gets thrown away.

* Types are incredibly valuable on hardened production code.

* Most good production code started out spikey, experimental or as an MVP and transitioned.

And so here we are with gradual typing because "throwing away all the code and rewriting it to be "perfect" in another language" has been known for years to be a shitty way to build products.

Im mystified that more people here dont see that the value and cost of types is NOT binary ("they're good! theyre bad!") but exists on a continuum that is contingent on the status of the app and sometimes even the individual feature.

zero_bias• 10 months ago

Python is ubiquitous in ML, often you have no choice but to use it

aurareturn• 10 months ago

Javascript is no longer was just scripting. Very large and complex billion dollar apps were being written in pure Javascript. It grew up.

I guess Python is next.

Elucalidavah• 10 months ago

how all the popular dynamic languages have slowly become statically typed

Count the amount of `Any` / `unknown` / `cast` / `var::type` in those codebases, and you'll notice that they aren't particularly statically typed.

The types in dynamic languages are useful for checking validity in majority of the cases, but can easily be circumvented when the types become too complicated.

It is somewhat surprising that dynamic languages didn't go the pylint way, i.e. checking the codebase by auto-determined types (determined based on actual usage).

jakobnissen2• 10 months ago

Julia (by default) does the latter, and its terrible. It makes it a) slow, because you have to do nonlocal inference through entire programs, b) impossible to type check generic library code where you have no actual usage, c) very hard to test that some code works generically, as opposed to just with these concrete types, and finally d) break whenever you have an Any anywhere in the code so the chain of type information is broken.

pansa211• 10 months ago

all the popular dynamic languages have slowly become statically typed

I’ve heard this before, but it’s not really true. Yes, maybe the majority of JavaScript code is now statically-typed, via Typescript. Some percentage of Python code is (I don’t know the numbers). But that’s about it.

Very few people are using static typing in Ruby, Lua, Clojure, Julia, etc.

Kwpolska• 10 months ago

How many people are using Ruby, Lua, Clojure, Julia, etc.?

Hamuko• 10 months ago

I have my doubts about majority of JavaScript being TypeScript.

majoe• 10 months ago

I disagree for Julia, but that probably depends on the definition of static typing.

For the average Julia package I would guess, that most types are statically known at compile time, because dynamic dispatch is detrimental for performance. I consider, that to be the definition of static typing.

That said, Julia functions seldomly use concrete types and are generic by default. So the function signatures often look similar to untyped Python, but in my opinion this is something entirely different.

iLoveOncall• 10 months ago

PHP as well has become statically typed.

All the languages you name are niche languages compared to Python, JS (/ TS) and PHP. Whether you like it or not.

tinnet• 10 months ago

At least in ruby theres mayor code bases using stripes sorbet and the official RBS standard for type hints. Notably its big code bases with large amounts of developers, fitting in with the trend most people in this discussion point to.

jascha_eng• 10 months ago

Types become very useful when the code base reaches a certain level of sophistication and complexity. It makes sense that for a little script they provide little benefit but once you are working on a code base with 5+ engineers and no longer understand every part of it having some more strict guarantees and interfaces defined is very very helpful. Both for communicating to other devs as well as to simply eradicate a good chunk of possible errors that happen when interfaces are not clear.

seanparsons4• 10 months ago

My last job was working at a company that is notorious for Ruby and even though I was mostly distant from it, there seemed to be a big appetite for Sorbet there.

vladms• 10 months ago

I like static types but advocating for enforcing them in any situation is different. Adding them when you need (Python currently) seems a better strategy than forcing you to set them always (Typescript is in between as many times it can determine them).

Many years ago I felt Java typing could be overkill (some types could have been deduced from context and they were too long to write) so probably more an issue about the maturity of the tooling than anything else.

flohofwoe• 10 months ago

OTH I only came to realize that I actually like duck typing in some situations when I tried to add type hints to one of my Python projects (and then removed them again because the actually important types consisted almost entirely of sum types, and what's the point of static typing if anything is a variant anyway).

E.g. when Python is used as a 'scripting language' instead of a 'programming language' (like for writing small command line tools that mainly process text), static typing often just gets in the way. For bigger projects where static typing makes sense I would pick a different language. Because tbh, even with type hints Python is a lousy programming language (but a fine scripting language).

lolive6• 10 months ago

Note1: Type hints are hints for the reader. If you cleverly discovered that your function is handling any type of data, hint that!

Note2: From my experience, in Java, i have NEVER seen a function that consumes explicitely an Object. In Java, you always name things. Maybe with parametric polymorphism, to capture complex typing patterns.

Note 3: unfortunately, you cannot subclass String, to capture the semantic of its content.

lelanthran6• 10 months ago

Because tbh, even with type hints Python is a lousy programming language (but a fine scripting language).

I'd be interested in seeing you expand on this, explaining the ways you feel Python doesn't make the cut for programming language while doing so for scripting.

The reason I say this is because, intuitively, I've felt this way for quite some time but I am unable to properly articulate why, other than "I don't want all my type errors to show up at runtime only!"

integralid• 10 months ago

If you like dynamic types have you considered using protocols? They are used precisely to type duck typed code.

zo1• 10 months ago

Sounds to be more of a symptom of the types of programs and functions you have written, rather than something inherent about types or Python. I've never encountered the type of gerry-mangled scenario you have described no matter how throwaway the code is.

lolive6• 10 months ago

Next stop is to agree that JSON is really NOT the semantic data exchange serialization for this "properly typed" world.

dotancohen3• 10 months ago

Then what is?

Everybody knows the limitations of JSON. Don't state the obvious problem without stating a proposed solution.

bushbaba• 10 months ago

I think both found middle ground. In Java you don’t need to define the type of variables within the method. In Python people have learned types in method arguments is a good thing.

isodev• 10 months ago

After decades of people saying

You have to admit that the size and complexity of the software we write has increased dramatically over the last few "decades". Looking back at MVC "web applications" I've created in the early 2000s, and comparing them to the giant workflows we deal with today... it's not hard to imagine how dynamic typing was/is ok to get started, but when things exceed one's "context", you type hints help.

jmorenoamor• 10 months ago

Coming from Java extreme verbosity, I just loved the freedom of python 20 years ago. Working with complex structures with mixed types was a breeze.

Yes, it was your responsibility to keep track of correctness, but that also taught me to write better code, and better tests.

procaryote5• 10 months ago

Writing tests is harder work than writing the equvalent number of type hints though

ivanjermakov• 10 months ago

Writing and maintaining tests that just do type checking is madness.

Dynamic typing also gives tooling such as LSPs and linters a hard time figuring out completions/references lookup etc. Can't imagine how people work on moderate to big projects without type hints.

afiori4• 10 months ago

In the discussion of static vs dynamic typing solutions like typescript or annotated python were not really considered.

IMHO the idea of a complex and inference heavy type system that is mostly useless at runtime and compilation but focused on essentially interactive linting is relatively recent and its popularity is due to typescript success

I think that static typing proponents were thinking of something more along the lines of Haskell/OCaml/Java rather than a type-erased system a language where [1,2] > 0 is true because it is converted to "NaN" > "0"

al_be_back• 10 months ago

dynamically-typed languages were typically created for scripting tasks - but ended up going viral (in part due to d-typing), the community stretched the language to its limits and pushed it into markets it wasn't designed/thought for (embedded python, server-side js, distributed teams, dev outsourcing etc).

personally i like the dev-sidecar approach to typing that Python and JS (via TS) have taken to mitigate the issue.

kubb2• 10 months ago

What I would need is a statically typed language that has first class primitives for working with untyped data ergonomically.

I do want to be able to write a dynamically typed function or subsystem during the development phase, and „harden” with types once I’m sure I got the structure down.

But the dynamic system should fit well into the language, and I should be able to easily and safely deal with untyped values and convert them to typed ones.

promiseofbeans• 10 months ago

So… Typescript?

pjmlp2• 10 months ago

Thing is, famous dynamic languages of the past, Common Lisp, BASIC, Clipper, FoxPro, all got type hints for a reason, then came a new generation of scripting languages made application languages, and everyone had to relearn why the fence was in the middle of the field.

cardanome• 10 months ago

slowly become statically typed

They don't. They become gradually typed which is a thing of it's own.

You can keep the advantages of dynamic languages, the ease of prototyping but also lock down stuff when you need to.

It is not a perfect union, generally the trade-off is that you can either not achieve the same safety level as in a purely statically typed language because you need to provide same escape hatches or you need a extremely complex type system to catch the expressiveness of the dynamic side. Most of the time it is a mixture of both.

Still, I think this is the way to go. Not dynamic typing won or static typing won but both a useful and having a language support both is a huge productivity boost.

Sharlin• 10 months ago

Everything goes in cycles. It has happened before and it will happen again. The softward industry is incredibly bad at remembering lessons once learned.

mhitza2• 10 months ago

I think you're ignoring how for some of us, gradual typing, is a far better experience than languages with static types.

For example what I like about PHPStan (tacked on static analysis through comments), that it offers so much flexibility when defining type constraints. Can even specify the literal values a function accepts besides the base type. And subtyping of nested array structures (basically support for comfortably typing out the nested structure of a json the moment I decode it).

seanparsons4• 10 months ago

Not ignoring, I just didn't write an essay. In all that time working with TypeScript there was very little that I found to be gradually typed, it was either nothing or everything, hence my original comment. Sure some things might throw in a bunch of any/unknown types but those were very much the rarity and often some libraries were using incredibly complicated type definitions to make them as tight as possible.

crabbone4• 10 months ago

Same nonsense repeated over and over again... There aren't dynamic languages. It's not a thing. The static types aren't what you think they are... You just don't know what you are saying and your conclusion is just a word salad.

What happened to Python is that it used to be a "cool" language, whose community liked to make fun of Java for their obsession with red-taping, which included the love for specifying unnecessary restrictions everywhere. Well, just like you'd expect from a poorly functioning government office.

But then everyone wanted to be cool, and Python was adopted by the programming analogue of the government bureaucrats: large corporations which treat programming as a bureaucratic mill. They don't want fun or creativity or one-of bespoke solutions. They want an industrial process that works on as large a scale as possible, to employ thousands of worst quality programmers, but still reliably produce slop.

And incrementally, Python was made into Java. Because, really, Java is great for producing slop on an industrial scale. But the "cool" factor was important to attract talent because there used to be a shortage, so, now you have Python that was remade to be a Java. People who didn't enjoy Java left Python over a decade ago. So that Python today has nothing in common with what it was when it was "cool". It's still a worse Java than Java, but people don't like to admit defeat, and... well, there's also the sunk cost fallacy: so much effort was already spent at making Python into a Java, that it seems like a good idea to waste even more effort to try to make it a better Java.

ModernMech2• 10 months ago

Yeah, this is the lens through which I view it. It's a sort of colonization that happens, when corporations realize a language is fit for plunder. They start funding it, then they want their people on the standards boards, then suddenly the direction of the language is matched very nicely to their product roadmap. Meanwhile, all the people who used to make the language what it was are bought or pushed out, and the community becomes something else entirely.

whizzter3• 10 months ago

That's because many do small things that don't really need it, sure there are some people doing larger stuff and are happy to be the sole maintainer of a codebase or replace the language types with unit-test type checks.

And I think they can be correct for rejecting it, banging out a small useful project (preferably below 1000 loc) flows much faster if you just build code doing things rather than start annotating (that quickly can be come a mind-sinkhole of naming decisions that interrupts a building flow).

However, even less complex 500 loc+ programs without typing can become a pita to read after the fact and approaching 1kloc it can become a major headache to pick up again.

Basically, can't beat speed of going nude, but size+complexity is always an exponential factor in how hard continuing and/or resuming a project is.

ktosobcy2• 10 months ago

Well, we do coalesce on certain things... some static type languages are dropping type requirements (Java and `var` in certain places) :D

constantcrying2• 10 months ago

var does absolutely nothing to make Java a less strictly typed language. There is absolutely no dropping of the requirement that each variable has a type which is known at compile time.

Automatic type inference and dynamic typing are totally different things.

moefh• 10 months ago

There's no dropping of type requirements in Java, `var` only saves typing.

When you use `var`, everything is as statically typed as before, you just don't need to spell out the type when the compiler can infer it. So you can't (for example) say `var x = null` because `null` doesn't provide enough type information for the compiler to infer what's the type of `x`.

constantcrying2• 10 months ago

The need for typing changed, when the way the language is used changed.

When JavaScript programs were a few hundred lines to add interactivity to some website type annotationd were pretty useless. Now the typical JavaScript project is far larger and far more complex. The same goes for python.

LudwigNagasena3• 10 months ago

Static typing used to be too rigid and annoying to the point of being counterproductive. After decades of improvement of parsers and IDEs they finally became usable for rapid development.

DarkNova62• 10 months ago

Huh. It's almost like these people didn't know what they were talking about. How strange.

tetha• 10 months ago

I think that the practically available type checkers evolved to a point where many of the common idioms can be expressed with little effort.

If one thinks back to some of the early statically typed languages, you'd have a huge rift: You either have this entirely weird world of Caml and Haskell (which can express most of what python type hints have, and could since many years), and something like C, in which types are merely some compiler hints tbh. Early Java may have been a slight improvement, but eh.

Now, especially with decent union types, you can express a lot of idioms of dynamic code easily. So it's a fairly painless way to get type completion in an editor, so one does that.

theptip2• 10 months ago

Type hints / gradual typing is crucially different from full static typing though.

It’s valid to say “you don’t need types for a script” and “you want types for a multi-million LOC codebase”.

jshen2• 10 months ago

Trends change. There is still no hard evidence that static types are net positive outside of performance.

screye• 10 months ago

AI tab-complete & fast LSP implementations made typing easy. The tools changed, and people changed their minds.

JSON's interaction with types is still annoying. A deserialized JSON could be any type. I wish there was a standard python library that deserialized all JSON into dicts, with opinionated coercing of the other types. Yes, a custom normalizer is 10 lines of code. But, custom implementations run into the '15 competing standards' problem.

Actually, there should be a popular type-coercion library that deals with a bunch of these annoying scenarios. I'd evangelize it.

alex_suzuki• 10 months ago

I recently discovered that the folks building uv and ruff are also building a type checker, and it already works really well (and fast!), despite beta status:

https://github.com/astral-sh/ty

Marazan2• 10 months ago

My view on typing in Python (a language I have used for decades) is that if I wanted types I would use a language designed from the ground up with strong and consistent typing built-in. Not bolt on a sort of type system which actively fights against the way I use the language on a day to day basis.

I use plenty of statically typed languages, Python's type hinting does not bring me joy.

Hackbraten4• 10 months ago

Not bolt on a sort of type system which actively fights against the way I use the language on a day to day basis.

Can you help me out with an example of a Python usage pattern against which the type system seems to be fighting?

Marazan2• 10 months ago

Ok, so this is just one of many examples but the most immediate one is where I don't care about the immutable sanctity of the variable I have just declared.

I often use Python for data munging and I'll frequently write code that goes

  foo = initial_value
  ...
  foo = paritally_cleaned_up_value
  ...
  if check:
   foo = fianllylikethis
  else:
   foo = orlikethis

Where the type of the value being assigned to foo is different each time. Now, obviously (in this simplistic example that misses subtleties) I could declare a new variable for each transformation step or do some composite type building type thing or refactor this into separate functions for each step that requires a different type but all of those options are unnecessary busy work for what should be a few simple lines of code.

JackSlateur3• 10 months ago

One can hope that cpython will use them, one day

"if a parameter is typed as an int, then only run the specialized 'int' code to process it"

This would increase performance and make typing more useful

aunderscored2• 10 months ago

Without significant language changes, this is not possible. While your code may be typed as an int, I can simply redefine what int means. I can also modify the code in your method.

JackSlateur3• 10 months ago

Yes

I guess it would work with the ongoing jit work, which (as far as I understood..) run the code "as usual", then notice that a specific variable is always a dict (or whatever). Then it patches the code to run the dict-optimized code by default (and fallback to the generic code if, somehow, the variable is no longer a dict).

With typing, the generic code could be avoided altogether. The algorithm would be:

  - notice that some variable can be processed by a dict-optimized code (because its typing is a dict, or something that looks like a dict etc)
  - when processing, check that the variable is indeed a "dict", raise an exception if not
  - run the optimized code
  - if the typing information changes (because the class has been redefined and the variable is no longer a "dict"), then go to step 1 and either stick with the current optimized code, use another one, or use the generic one

This would:

  - enforce types (you said that variable is a Thing but a Thing was not given: exception)
  - improve the jit by removing the bootstrap phase (where the jit watches and then try to guess what could be improved)

(or perhaps this is a stupid idea that cannot work :) )

ciupicri2• 10 months ago

I think you're forgetting that int is actually what other people call a BigInt, an integer with unlimited precision, not int32 or int64.

picafrost• 10 months ago

My experience adding types to un-typed Python code has convinced me that static typing should be required for anything more complicated than a single purpose script. Even in old and battle tested code bases so many tiny bugs and false assumptions are revealed and then wiped out.

It's not perfect in Python, and I see some developers introduce unnecessary patterns trying to make type-"perfect" `class Foo(Generic[T, V])` (or whatever) abstractions where they are not really necessary. But if the industry is really going all-in on Python for more than scripting, so should we for typed Python.

entropyneur• 10 months ago

I know I am going to be in the minority, but I don't understand why we can't let Python be Python. Static typing is great, and there are already other statically typed languages for all your needs. Why not use them?

Well, at least it doesn't create two incompatible Pythons like async and (I assume) free threading.

Galanwe• 10 months ago

I used to be of the same opinion, but after giving type hints a real try, I changed my mind.

You should not see type hints as real, hard types, but more as a kind of documentation that helps your linter and type checker catch mistakes.

Matthyze2• 10 months ago

Why not use them?

Because you can now use typing WITH the entire Python ecosystem.

Ekaros2• 10 months ago

I sometimes felt that Python was rather strong in many parts of typing. As such being able to track what type of something is would often have been useful. Instead of waiting it to crash to some error.

Like back in 2.7 difference between byte-array and string... Offloading such cases is mentally useful.

chpatrick13• 10 months ago

Because Python has a lot of things it's great at (numeric stuff, ML, computer vision, scripting), and with types you can actually rely on it to work. It's the best of both worlds.

gooodvibes• 10 months ago

Isn't this a very 2018-2019 topic? I don't get the motivation to write about it in 2025, it's like telling people to use version control.

Hackbraten4• 10 months ago

https://xkcd.com/1053/

yoshi389111• 10 months ago

Beyond the usual advantages of Python’s type hints, it seems they can also improve code suggestions and completions when working with AI coding tools.

ciupicri2• 10 months ago

Is there a type checker that works with numbers.Number?

spooky_deep• 10 months ago

Python with type hints still lacks the performance benefits of static typing in a compiled language setting?

maxfurman• 10 months ago

It's the developer performance benefit of catching type bugs early, not the application performance benefit from a compiler, that Python developers find compelling

pansa211• 10 months ago

Yes. It also lacks the ease-of-deployment of a compiled language.

chpatrick13• 10 months ago

You generally don't write Python if you want it to be really fast anyway (non-Python parts like numpy notwithstanding).

tmarice• 10 months ago

Type hints in Python add a great amount of visual noise to the code, and I actively avoid them wherever possible. If static typing is a must, use a language where static typing is not an afterthought, and let Python be Python.

ctxc2• 10 months ago

I guess one man's noise is another man's treasure :P

corwinxpro• 10 months ago

Indeed, I almost can't read untyped python code these days. It just feels like "what the hell is going on here?" and "what is this object?" ever so often. Sorry to say that but most people who write python just aren't good API designers, or software engineers in general, and type hints can at least help others get a vague idea of what the intent was.

chrysoprace2• 10 months ago

Would you rather deal with a little visual noise or a runtime exception that you could've caught before code got to production? For me it's about tradeoffs, and so far the tradeoff has been well worth it.

mixmastamyk10• 10 months ago

We have a reliable codebase with tests, pyflakes, sentry, etc. Very few issues make it to prod, though a few might make it to staging.

That said, I’m looking into the stubs.

mgaunard• 10 months ago

in general I see two types of Python in the wild: - simple self-contained scripts, everything is a free function, no type hints - over-engineered hierarchies of classes spread over dozens of files and modules, type hints everywhere

I personally largely prefer the first kind, but it seems even the standard formatting rules are against it (two empty lines between free functions etc.)

Matthyze2• 10 months ago

I'm always surprised when people suggest using a different language if you want typing in Python. Python's (second?) largest appeal is probably its extensive ecosystem. Whenever people suggest just changing languages, I wonder if they work in isolation, without the need for certain packages or co-worker proficiency in that language.

sigmoid10• 10 months ago

Typing has only been around since python 3.5. As someone who has formally learned 2.7 in university when 3.0 had already been around for a few years, I suppose there are many who still lag years behind what the language can do due to old codebases and fears of incompatibility.

f311a• 10 months ago

I think people usually say it for a different reason. Types are not enforced. You can annotate your code that looks correct to the type checker, but the actual data flow at runtime can be with different types.

And it happens quite often in large codebases. Sometimes external dependencies report wrong types, e.g., a tuple instead of a list. It's easy to make such a mistake when a library is written in a compiled language and just provides stubs for types. Tuples and lists share the same methods, so it will work fine for a lot of use cases. And since your type checker will force you to use a tuple instead of a list, you will never know that it's actually a list that can be modified unless you disable type checking and inspect the data.

chpatrick13• 10 months ago

To be pedantic compiled languages only check types at compile time as well. If you have a C library that takes void* then it can easily go wrong at runtime.

ctxc2• 10 months ago

For some reason, I find typing in Python to be more ergonomic and "get out of your way" compared to Typescript.

But they both seem to handle typing similarly.

I can't put my finger on why. Anybody else?

chrysoprace2• 10 months ago

TypeScript is kind of all or nothing.

It's not quite all or nothing, but it's annoying to work with it if you only use it for some things and not for others. I find that if you have a mixture of TS and JS in various files I would rather just go all in on TypeScript so I don't have to manually annotate.

With Python you're still just working with Python files.

xurukefi• 10 months ago

For me, type hints are mainly useful because they're the only reliable way to get decent IDE auto-completion. Beyond that, they feel like a bolted-on compromise that goes against the spirit of Python. If you really need strict typing, you're probably better off using a statically typed language.

kitd• 10 months ago

JSDoc plays a similar role with Javascript. Moreover it is supported out of the box by VSCode, so add a few JSDoc comments to your types and functions, and intellisense instantly kicks in.

Dr_Birdbrain• 10 months ago

I actually don’t like python type hints!

At my work we have a jit compiler that requires type hints under some conditions.

Aside from that, I avoid them as much as possible. The reason is that they are not really a part of the language, they violate the spirit of the language, and in high-usage parts of code they quickly become a complete mess.

For example a common failure mode in my work’s codebase is that some function will take something that is indexable by ints. The type could be anything, it could be List, Tuple, Dict[int, Any], torch.Size, torch.Tensor, nn.Sequential, np.ndarray, or a huge host of custom types! And you better believe that every single admissible type will eventually be fed to this function. Sometimes people will try to keep up, annotating it with a Union of the (growing) list of admissible types, but eventually the list will become silly and the function will earn a # pyre-ignore annotation. This defeats the whole point of the pointless exercise.

So, if the jit compiler needs the annotation I am happy to provide it, but otherwise I will proactively not provide any, and I will sometimes even delete existing annotations when they are devolving into silliness.

detaro2• 10 months ago

Can't you define your own hint for "type that has __getitem__ taking int"?

crabbone4• 10 months ago

The way I understand parent is that such a type would be too broad.

The bigger problem is that the type system expressed through hints in Python is not the type system Python is actually using. It's not even an approximation. You can express in the hint type system things that are nonsense in Python and write Python that is nonsense in the type system implied by hints.

The type system introduced through typing package and the hints is a tribute to the stupid fashion. But, also, there is no syntax and no formal definitions to describe Python's actual type system. Nor do I think it's a very good system, not to the point that it would be useful to formalize and study.

In Russian, there's an expression "like a saddle on a cow", I'm not sure what the equivalent in English would be. This describes a situation where someone is desperately trying to add a desirable feature to an exiting product that ultimately is not compatible with such a feature. This, in my mind, is the best description of the relationship between Python's actual type system and the one from typing package.

thr0w4w4y13372• 10 months ago

from typing import Protocol, TypeVar

T_co = TypeVar("T_co", covariant=True)

class Indexable(Protocol[T_co]): def __getitem__(self, i: int) -> T_co: ...

def f(x: Indexable[str]) -> None: print(x[0])

I am failing to format it proprely here, but you get the idea.

matusp• 10 months ago

There is also bunch of prepackaged types, such as collections.abc.Sequence that could be used in this case.

whilenot-dev3• 10 months ago

Just fyi: https://news.ycombinator.com/formatdoc

Text after a blank line that is indented by two or more spaces is reproduced verbatim. (This is intended for code.)

If you'd want monospace you should indent the snippet with two or more spaces:

  from typing import Protocol, TypeVar
  
  T_co = TypeVar("T_co", covariant=True)
  
  class Indexable(Protocol[T_co]):
    def __getitem__(self, i: int) -> T_co: ...
  
  def f(x: Indexable[str]) -> None:
    print(x[0])

amluto• 10 months ago

I give Rust a lot of points for putting control over covariance into the language without making anyone remember which one is covariance and which one is contravariance.

dragonwriter12• 10 months ago

As of Python 3.12, you don’t need separately declared TypeVars with explicit variance specifications, you can use the improved generic type parameter syntax and variance inference.

So, just:

  class Indexable[T](Protocol):
    def __getitem__(self, i: int,/) -> T: ...

is enough.

unethical_ban• 10 months ago

It sounds like that function is rightfully eligible to be ignored or to use the Any designation. To me that's why the system is handy. For functions that have specific inputs and outputs, it helps developers keep things straight and document code.

For broad things, write Any or skip it.

9dev2• 10 months ago

That's the same complaints people had about TypeScript in the beginning, when libraries such as Express used to accept a wide range of input options that would be a pain to express in types properly. If you look at where the ecosystem is now, though, you'll see proper type stubs, and most libraries get written in TS in the first place anyway. When editing TS code, you get auto-completion out of the box, even for deeply nested properties or conditional types. You can rely on types being what the compiler says they are, and runtime errors are a rarity now (in properly maintained code bases).

The reason is that they are not really a part of the language, they violate the spirit of the language, and in high-usage parts of code they quickly become a complete mess.

I'll admit that this is what I hate Python, and it's probably this spirit of the language as you call it. I never really know what parameters a function takes. Library documentation often shows a few use cases, but doesn't really provide a reference; so I end up having to dig into the source code to figure it out on my own. Untyped and undocumented kwargs? Everywhere. I don't understand how someone could embrace so much flexibility that it becomes entirely undiscoverable for anyone but maintainers.

zelphirkalt6• 10 months ago

Because the flexibility has been a boon and not a problem. The problem only comes when you try to express everything in the type system, that is third party (the type checkers for it) and added on top.

Izkata2• 10 months ago

Except Typescript embraces duck typing. You can say "accept any object with a quack() method", for example, and it'll accept an unexpected quacking parrot. It can even tell when two type definitions are close enough and merge them.

kketch3• 10 months ago

They don’t violate the spirit of the language. They are optional. They don’t change the behaviour at runtime.

Type annotations can seem pointless indeed if you are unwilling to learn how to use them properly. Using a giant union to type your (generic) function is indeed silly, you just have to make that function generic as explained in another comment or I guess remove the type hints

pansa211• 10 months ago

They don’t violate the spirit of the language. They are optional.

That in itself violates the spirit of the language, IMO. “There should be one obvious way to do it”.

zelphirkalt6• 10 months ago

Yeah, but then you get into the issues with when and where generic types are bound and narrowed, which can then make it more complicated, at which point one might be better off stepping back, redesigning, or letting go of perfect type hint coverage, for dynamic constructs, that one couldn't even write in another type safe language.

yladiz• 10 months ago

Actually in Python it can. Since the type hints are accessible at runtime, library authors can for example change which values in kwargs are allowed based on the type of the argument.

So on the language level it doesn’t directly change the behavior, but it is possible to use the types to affect the way code works, which is unintuitive. I think it was a bad decision to allow this, and Python should have opted for a TypeScript style approach.

j1elo2• 10 months ago

No idea about Python type system, but doesn't it have anything like this?

  interface IntIndexable {
    [key: number]: any
  }

sdeframond2• 10 months ago

It does!

You can specify a protocol like this:

  class IntIndexable(Protocol[T]):
    def __getitem__(self, index: int, /) -> T: ...

(Edit: formatting)

tdeck5• 10 months ago

I like Python a lot, and have been using it for personal projects since about 2010. It was only once I started working and encountering long-lived unfamiliar Python codebases regularly that I understood the benefits of type hints. It's not fun to have to trace through 5 or 6 different functions to try to figure out what type is being passed in or returned from something. It's even less fun to find out that someone made a mistake and it's actually two different incompatible things depending on the execution path.

That era of Python codebases were miserable to work in, and often ended up in the poorly though out "we don't know how this works and it has too many bugs, let's just rewrite it" category.

rlpb• 10 months ago

It's not fun to have to trace through 5 or 6 different functions to try to figure out what type is being passed in or returned from something.

My position is that what is intended must be made clear between type hints and the docstring. Skipping this makes for difficult to read code and has no place in a professional setting in any non-trivial codebase.

This doesn't require type hints to achieve. :param and :rtype in the docstring are fine if type hints aren't present, or for complex cases, plain English in the docstring is usually better.

boltzmann64• 10 months ago

I am sorry, but whats wrong with doing something like, `print(type(var)); exit()` and just running it once instead of digging through 5-6 stack frames?

TZubiri3• 10 months ago

So the type is anything that implements the index function ([], or __getitem__), I thnink that's a Sequence, similar to Iterable.

from typing import Sequence
def third(something: Sequence):
return indexable[3]

however if all you are doing is just iterate over the thing, what you actually need is an Iterable

from typing import Iterable
def average(something:Iterable):
for thing in something:
...

Statistically, the odds of a language being wrong, are much lower than the programmer being wrong. Not to say that there aren't valid critiques of python, but we must think of the creators of programming languages and their creations as the top of the field. If a 1400 chess elo player criticizes Magnus Carlsen's chess theory, it's more likely that the player is missing some theory rather than he found a hole in Carlsen's game, the player is better served by approaching a problem with the mentality that he is the problem, rather than the master.

pansa211• 10 months ago

we must think of the creators of programming languages and their creations as the top of the field

The people at the top of the type-system-design field aren’t working on Python.

bgwalter4• 10 months ago

That is sort of ironic because the Pythonistas did not leave out any opportunity to criticize Java. Java was developed by world class experts like Gosling and attracted other type experts like Philip Wadler.

No world class expert is going to contribute to Python after 2020 anyway, since the slanderous and libelous behavior of the Steering Council and the selective curation of allowed information on PSF infrastructure makes the professional and reputational risk too high. Apart from the fact that Python is not an interesting language for language experts.

Google and Microsoft have already shut down several failed projects.

dragonwriter12• 10 months ago

So the type is anything that implements the index function ([], or __getitem__), I thnink that's a Sequence

Sequence involves more than just __getitem__ with an int index, so if it really is anything int indexable, a lighter protocol with just that method will be more accurate, both ar conveying intent and at avoiding needing to evolve into an odd union type because you have something that a satisfies the function’s needs but not the originally-defined type.

coldtea5• 10 months ago

you better believe that every single admissible type will eventually be fed to this function

That's your problem right there. Why are random callers sending whatever different input types to that function?

That said, there are a few existing ways to define that property as a type, why not a protocol type "Indexable"?

knome• 10 months ago

why not a protocol type

it was a sin that python's type system was initially released as a nominal type system. they should have been the target from day one.

being unable to just say "this takes anything that you can call .hello() and .world() on" was ridiculous, as that was part of the ethos of the dynamically typed python ecosystem. typechecking was generally frowned upon, with the idea that you should accept anything that fit the shape the receiving code required. it allowed you to trivially create resource wrappers and change behaviors by providing alternate objects to existing mechanisms. if you wanted to provide a fake file that read from memory instead of an actual file, it was simple and correct.

the lack of protocols made hell of these patterns for years.

david4222• 10 months ago

Yes. It's not the type system that's broken, it's the design. Fix the design, and the type system works for you, not against you.

oivey3• 10 months ago

That's your problem right there. Why are random callers sending whatever different input types to that function?

Because it’s nice to reuse code. I’m not sure why anyone would think this is a design issue, especially in a language like Python where structural subtyping (duck typing) is the norm. If I wanted inheritance soup, I’d write Java.

Ironically, that’s support for structural subtyping is why Protocols exist. It’s too bad they aren’t better and the primary way to type Python code. It’s also too bad that TypedDict actively fought duck typing for years.

dragonwriter12• 10 months ago

Why are random callers sending whatever different input types to that function?

Probably because the actual type it takes is well-understood (and maybe even documented in informal terms) by the people making and using it, but they just don’t understand how to express it in the Python type system.

zenkey• 10 months ago

In my experience, the right tooling makes Python typing a big win. Modern IDEs give comprehensive real-time feedback on type errors, which is a big productivity boost and helps catch subtle bugs early (still nowhere near Rust, but valuable nonetheless). Push it too far though, and you end up with monsters like Callable[[Callable[P, Awaitable[T]]], TaskFunction[P, T]]. The art is knowing when to sprinkle types just enough to add clarity without clutter.

ddavis• 10 months ago

When you hit types like that type aliases come to the rescue; a type alias combined with a good docstring where the alias is used goes a long way

sevensor5• 10 months ago

I don’t know anything about your jit compiler, but generally the value I get from type annotations has nothing to do with what they do at runtime. People get so confused about Python’s type annotations because they resemble type declarations in languages like C++ or Java. For the latter, types tell the compiler how to look up fields on, and methods that apply to, an object. Python is fine without that.

Python’s types are machine-checkable constraints on the behavior of your code.. Failing the type checker isn’t fatal, it just means you couldn’t express what you were doing in terms it could understand. Although this might mean you need to reconsider your decisions, it could just as well mean you’re doing something perfectly legitimate and the type checker doesn’t understand it. Poke a hole in the type checker using Any and go on with your day. To your example, there are several ways described in comments by me and others to write a succinct annotation, and this will catch cases where somebody tries to use a dict keyed with strings or something.

Anyway, you don’t have to burn a lot of mental energy on them, they cost next to nothing at runtime, they help document your function signatures, and they help flag inconsistent assumptions in your codebase even if they’re not airtight. What’s not to like?

gostsamo• 10 months ago

why not a protocol with getitem with an int arg?

oivey3• 10 months ago

I feel pretty similarly on this. Python’s bolted on type system is very poor at encoding safe invariants common in the language. It’s a straight jacketed, Java-style OOP type system that’s a poor fit for many common Python patterns.

I would love it if it were better designed. It’s a real downer that you can’t check lots of Pythonic, concise code using it.

humdaanm• 10 months ago

the issue of having multiple inputs able to be indexable by ints, is exactly why i prefer that type hints remain exactly as "hints" and not as mandated checks. my philosophy for type hints is that they are meant to make codebases easier to understand without getting into a debugger. their functional equivalence should be that of comments. it's a cleaner more concise way of describing a variable instead of using a full on docstring.

though maybe there's a path forward to give a variable a sort of "de-hint" in that in can be everything BUT this type(i.e. an argument can be any indexable type, except a string)

true_blue• 10 months ago

though maybe there's a path forward to give a variable a sort of "de-hint" in that in can be everything BUT this type

I think this is called a negation type, and it acts like a logical NOT operator. I'd like it too, and I hear that it works well with union types (logical OR) and intersection types (logical AND) for specifying types precisely in a readable way.

lucasyvas• 10 months ago

This is like saying you don’t like nails because you don’t understand how to use a hammer though. Developers are not understanding how to use the hints properly which is causing you a personal headache. The hints aren’t bad, the programmers are untrained - the acknowledgement of this is the first step into a saner world.

jonas21• 10 months ago

eventually the list will become silly and the function will earn a # pyre-ignore annotation. This defeats the whole point of the pointless exercise.

No, this is the great thing about gradual typing! You can use it to catch errors and provide IDE assistance in the 90% of cases where things have well-defined types, and then turn it off in the remaining 10% where it gets in the way.

bartread• 10 months ago

The reason is that they are not really a part of the language, they violate the spirit of the language

This is a good way of expressing my own frustration with bolting strong typing on languages that were never designed to have it. I hate that TypeScript has won out over JavaScript because of this - it’s ugly, clumsy, and boilerplatey - and I’d be even more disappointed to see the same thing happen to the likes of Python and Ruby.

My background is in strongly typed languages - first C++, then Java, and C# - so I don’t hate them or anything, but nowadays I’ve come to prefer languages that are more sparing and expressive with their syntax.

mhitza2• 10 months ago

Sounds like the ecosystem needs an "indexable" type annotation. Make it an "indexable<int>" for good measure.

theptip2• 10 months ago

Right, this was my thought.

Can’t you just use a typing.Protocol on __getitem__ here?

https://typing.python.org/en/latest/spec/protocol.html

Something like

    from typing import Protocol

    class Indexable(Protocol):
        def __getitem__(self, i: int) -> Self: ...

Though maybe numpy slicing needs a bit more work to support

burnerRhodov2• 10 months ago

You explained some hyper niche instance where type hints should be ignored. 99% of the time, they are extremely helpful.

chlorion2• 10 months ago

It's not even a niche instance, protocols solve their problem lol.

fyrn_• 10 months ago

You can use a Protocol type for that, makes a lot mote sense than nominal typing for typing use case.

vjerancrnjak• 10 months ago

Exactly, sounds like misuse of unions.

Although Python type hints are not expressive enough.

the__alchemist2• 10 months ago

I like your point! I think the advantage in its light is this: People often use Python because it's convention in the domain, the project already uses it, or it's the language the rest of the team uses. So, you are perhaps violating the spirit, but that's OK. You are making the most of tools available. It's not the Platonic (Pythonic??) ideal, but good enough.

bobbiechen2• 10 months ago

Isn't this supported by typing.SupportsIndex? https://docs.python.org/3/library/typing.html#typing.Support...

Mind you, I haven't used it before, but it feels very similar to the abstract Mapping types.

detaro2• 10 months ago

__index__ is not what you think it is

thrance• 10 months ago

For this very specific example, isn't there something like "Indexable[int]"?

nurettin• 10 months ago

Why not do Indexable = Any and pass that? Even if it doesn't help your jit or the IDE, at least it is more explicit than

    def lol(blarg):  # types? haha you wish. rtfc you poor sod. Pytharn spirit ftw!!!
        ...
        return omg[0].wtf["lol freedom"].pwned(Good.LUCK).figuring * out

tickettotranai• 10 months ago

I mean, you can just... Not annotate something if creating the relevant type is a pain. Static analysis \= type hints, and even then...

Besides, there must be some behavior you expect from this object. You could make a type that reflects this: IntIndexable or something, with an int index method and whatever else you need.

This feels like an extremely weak argument. Just think of it as self-enforcing documentation that also benefits auto-complete; what's not to love? Having an IntIndexable type seems like a great idea in your use case.

rtpg• 10 months ago

For example a common failure mode in my work’s codebase is that some function will take something that is indexable by ints. The type could be anything, it could be List, Tuple, Dict[int, Any], torch.Size, torch.Tensor, nn.Sequential, np.ndarray, or a huge host of custom types! And you better believe that every single admissible type will eventually be fed to this function. Sometimes people will try to keep up, annotating it with a Union of the (growing) list of admissible types, but eventually the list will become silly and the function will earn a # pyre-ignore annotation. This defeats the whole point of the pointless exercise.

You are looking for protocols. A bit futzy to write once but for a heavily trafficked function it's woth it.

If your JIT compiler doesn't work well with protocols... sounds like a JIT problem not a Python typing problem

chlorion2• 10 months ago

The type could be anything, it could be List, Tuple, Dict[int, Any], torch.Size, torch.Tensor, nn.Sequential, np.ndarray, or a huge host of custom types!

That's not how you are supposed to use static typing? Python has "protocols" that allows for structural type checking which is intended for this exact problem.

spicyusername• 10 months ago

    And you better believe that every single admissible type

This is exactly why I hate using Python.

albrewer• 10 months ago

Define a protocol[0] that declares it implements `__getitem__` and type annotate with that protocol. Whatever properties are needed inside the function can be described in other protocols.

These are similar to interfaces in C# or traits in Rust - you describe what the parameter _does_ instead of what it _is_.

[0] https://typing.python.org/en/latest/spec/protocol.html

fragmede• 10 months ago

something that is indexable by ints. ...Dict[int, Any]...

If that is exactly what you want, then define a Protocol: from __future__ import annotations from typing import Protocol, TypeVar

    T = TypeVar("T")
    K = TypeVar("K")
    
    class GetItem(Protocol[K, T]):
        def __getitem__(self, key: K, /) -> T: ...
    
    
    def first(xs: GetItem[int, T]) -> T:
        return xs[0]

Then you can call "first" with a list or a tuple or a numpy array, but it will fail if you give it a dict. There is also collections.abc.Sequence, which is a type that has .__getitem__(int), .__getitem__(slice), .__len__ and is iterable. There are a couple of other useful ones in collections.abc as well, including Mapping (which you can use to do Mapping[int, t], which may be of interest to you), Reversible, Callable, Sized, and Iterable.

jlnthws• 10 months ago

Use them for what they are (hints, documentation). Use it for gradual typing when implementation makes it hard to understand return or parameters types. But don't enforce it across your code base, use another language or another mindset instead.

ktosobcy2• 10 months ago

I liked python in my early days because it felt simple and easy and when I tried other languages having to deal with types felt so annoying... but then I grew and had to work with bigger codebases and guess what - having types (and static type checking during compilatin) helps A LOT... :)

physicsguy• 10 months ago

I like it but in my experience a lot of teams use them loosely without a type checker, more for understanding than for correctness. Reason for that is largely that it can be difficult to make the checkers happy…

procaryote5• 10 months ago

I like the type hints. The're not perfect and they've changed a lot between versions, but they really help catch issues early that you'd usually need to write unit tests for. Adding type hints is easier than writing those unit tests.

Then you can focus your tests on more interesting things

You just need to set your build up to actually do the checking as type hints by default are just documentation

setopt• 10 months ago

My main complaint about them is no first-party support for type checking, you need external packages like beartype decorators.

procaryote5• 10 months ago

Yeah, it would have been much better to have them be default enforces if present. Keeping them optional is fine, but I don't get the use-case for "you can add them but not check them"... that just leads to actively misleading hints

zelphirkalt6• 10 months ago

Python's dynamic nature can make it quite difficult to express some things correctly. That, or the type checkers have issues when it comes to understanding what would be considered safe in other languages. Years ago when I knew far less about types and programming, I never had such problems in for example Java. It was sometimes stupid, but I always found a way to express things. Although it could also be, that I merely want more out of inference and and safety. For example recently I wanted a pipeline of steps, but the steps could have any input and output type, as long as that type aligns with the previous step's types and the type checker should also know what the final output type is, and I additionally wanted it to work so that I don't have to add all the steps at once, so that I can construct the pipeline step by step. Tried for hours, but didn't find a working solution that type checks. Also tried with the help of LLMs, which gave superficially looking great code for this, but then there was always some type error somewhere, and they struggled to fix that. Ultimately, I gave up on the type checking between steps and output type of the pipeline, as I realized, that I invested hours into something that might be impossible or way waaay too much work for what I get from it. I would not have spent any time on this without type annotating and would have simply gone with a dynamic solution.

whilenot-dev3• 10 months ago

That doesn't sound like it'd have something to do with the dynamic nature of python. Type checking is a static analysis of the source code, so if you'd want something to be inferred dynamically, then you'll have to make use of generics:

  from typing import Callable
  
  
  class Pipeline[T]:
    def __init__(self, value: T) -> None:
      self._value = value
  
    def step[U](self, cb: Callable[[T], U]) -> 'Pipeline[U]':
      return Pipeline(cb(self._value))
  
    def terminate(self) -> T:
      return self._value
  
  
  def _float_to_int(value: float) -> int:
    return int(value)
  
  
  def _int_to_str(value: int) -> str:
    return str(value)
  
  
  def main() -> None:
    result = Pipeline(3.14)\
      .step(_float_to_int)\
      .step(_int_to_str)\
      .terminate()
    
    print(result)

  
  if __name__ == '__main__':
    main()

You could further constrain the generic type through type variables: https://docs.python.org/3/library/typing.html#typing.TypeVar

zelphirkalt6• 10 months ago

I think this pipeline implementation does some things different from what I wanted (but did not precisely describe. It seems that each step is run right away, as it is "added", rather than collected and run when `terminate` is called. Also each step can only consume the result of the previous step, not the results of earlier steps. This can be worked around, by ending the pipeline and then starting multiple pipelines from the result of the first pipeline, if needed. I think you would need to import Generic and write something like `class Pipeline(Generic[T]):` as well? Or is `class Pipeline[T]:` a short form of that?

In my experiment I wanted to get a syntax like this:

    pipeline = Pipeline()

    ...some code here...

    pipeline.add_step(Step(...some meta data..., ...actual procedure to run...))

So then I would need generics for `Step` too and then Pipeline would need to change result type with each call of `add_step`, which seems like current type checkers cannot statically check.

I think your solution circumvents the problem maybe, because you immediately apply each step. But then how would the generic type work? When is that bound to a specific type?

ksynwa• 10 months ago

How do type hints work if for example you import a library that has not implemented type hints into your project in which you hope to have type hints? Do you just manually assign types to the outputs of this library?

geenat• 10 months ago

Company selling a product based on what's being glazed in the article.

It's always a small vocal fraction or they'd be using a different language.

davidatbu• 10 months ago

I doubt that Meta (the company that sponsors the work on pyrefly) is looking forward to selling a product based on Python typing (assuming that's what's "what's being glazed in the article").

storus• 10 months ago

They are optional until Pydantic is forced on you by some required library.

dvcoolarun• 10 months ago

I believe types are a great way to encourage good practices with relatively little investment. They provide type-safety, act as living documentation, and add an extra layer of protection in production.

However, in a large codebase, consistency can become a challenge. Different developers often approach the same problem in different ways, leading to a mix of type patterns and styles, especially when there’s no clear standard or when the problem itself is complex.

With the rise of LLM-generated code, this issue becomes even more pronounced — code quality and craftsmanship can easily degrade if not guided by proper conventions.

totalhack• 10 months ago

It's optional, and that's great, because its necessity or benefit is situational.

sota_pop6• 10 months ago

Python types - all the onus of static types, with none of the performance!

I enjoy packages like pydantic and SOME simple static typing, but if I’m implementing anything truly OOP, I wouldn’t first reach for Python anyway; the language doesn’t even do multiple constructors or public/private props.

Edit: as a side note, I was interested to learn that for more verbose type specification, it’s possible to define a type in variable-like syntax at the top: mytype = int|str|list|etc.

the__alchemist2• 10 months ago

There is an important (I would say primary) benefits of types that isn't performance: it's making a program structure [you | your IDE | LLMs] can reason about.

sota_pop6• 10 months ago

Agreed, it definitely improves my experience when the compiler “knows” the variable types.

coldtea5• 10 months ago

One shouldn't be implementing anything "trully OOP" to begin with...

sota_pop6• 10 months ago

Quotes speak louder than words… However it’s hard to say “what one should or shouldn’t” be implementing in general terms.

__MatrixMan__5• 10 months ago

What does "multiple constructors" buy you that you can't get from multiple static methods that return an object of the enclosing class's type.

Maybe I'm missing out on something cool...

sota_pop6• 10 months ago

Perhaps just a fuzzy feeling. I suppose I haven’t tried using static methods for that purpose. Will give it a shot!

blibble• 10 months ago

I find the type hints harder and slower than java/C/...

try typing a decorator, or anything using file IO

I find it extremely difficult, if not impossible, and I did type theory

(the type checkers being really, really stupid doesn't help either)

sevensor5• 10 months ago

So don’t? Just annotate the stuff that’s not annoying. I agree, IO is annoying to type. Decorators are fine, it’s just a function that returns a function. It’s still a win, however much you decide to annotate.

grumbel• 10 months ago

The most annoying part is that the type checking exists outside the regular runtime. I constantly run into situation where the type checker is happy, but the thing explodes at runtime or the type checker keeps complaining about working code. And different type checkers will even complain about different things regularly too. It's a whole lot of work making every part of the system happy and the result still feels extremely brittle.

sota_pop6• 10 months ago

They ARE only “hints” afterall.

throwaway1063823• 10 months ago

Ruby doesn't have multiple constructors and literally everything in Ruby is an object so it's partically impossible to avoid "doing OOP". I don't see how being "truely OOP" has anything to do with the language supporting method overloads.

marcosdumay4• 10 months ago

with none of the performance!

If you care about micro-optimizations, the first one that overwhelms everything else is to not use Python.

Anyway, if your types are onerous, you are using them wrong. Even more in a progressive type system where you always have the option of not using them or putting an "Any" there.

sota_pop6• 10 months ago

While most responders seem to have latched on to the pedantics of my “oop” comment - this is what my comment was intended to imply: why force the verbosity of static types on Python when statically typed (sic compiled) languages typically have much better runtime performance? the real answer i suspect is for quality of life/readability of code, but they are just “hints” afterall.

runeblaze• 10 months ago

Python types - all the onus of static types, with none of the power of calculus of constructions. /s

coldtea5• 10 months ago

More likely "Python developers phone-in AI code that uses type hints".

lupusreal• 10 months ago

Types are invaluable in modern code bases because they end up saving a ton of tokens when agentic coding tools are trying to comprehend let alone modify the code. Python isn't intrinsically a great language for LLMs to work with, except in practice it is because they've had a great deal of training data for python. Type hints help a lot with this.

pif• 10 months ago

Only lazy and lame developers can prefer dynamic type.

DarkNova62• 10 months ago

Shocker. Static typing wins once again.

david4222• 10 months ago

I used python on a large code base for quite a while. Many team members did not like type hints, and a codebase that doesn't maintain type hints makes it harder to use them.

However, if I had a choice, rather than use typehints in python, I would much rather just use a statically typed language. Short, tiny scripts in python? Sure. Anything that grows or lives a long time? Use something where the compiler helps you out.

olokobayusuf3• 10 months ago

I'm founding a company that is building an AOT compiler for Python (Python -> C++ -> object code) and it works by propagating type information through a Python function. That type propagation process is seeded by type hints on the function that gets compiled:

https://blog.codingconfessions.com/i/174257095/lowering-to-c...

franktankbank2• 10 months ago

Have you talked to anyone about where this flat out will not work? Obviously it will work in simple cases but someone with good language understanding will probably be able to point out cases where it just won't. I didn't read your blog so apologies if this is covered. How does this compiler fit into your company business plan?

olokobayusuf3• 10 months ago

Our primary use case is cross-platform AI inference (unsurprising), and for that use case we're already in production by startups to larger co's.

It's kind of funny: our compiler currently doesn't support classes, but we support many kinds of AI models (vision, text generation, TTS). This is mainly because math, tensor, and AI libraries are almost always written with a functional paradigm.

Business plan is simple: we charge per endpoint that downloads and executes the compiled binary. In the AI world, this removes a large multiplier in cost structure (paying per token). Beyond that, we help co's find, eval, deploy, and optimize models (more enterprise-y).

loglog2• 10 months ago

This sounds even worse than Modular/Mojo. They made their language look terrible by trying to make it look like Python, only to effectively admit that source compatibility will not really work any time soon. Is there any reason to believe that a different take on the same problem with stricter source compatibility will work out better?

throwaway1063823• 10 months ago

Ruby has had static typing via RBS for a while now, and I don't know if it's because I'm primarily a Rails developer and DHH doesn't like static typing so using these with Rails feels third-class or maybe just that I'm really just all the way in "the ruby way" but it feels antithetical to a dynamically typed language to start shoehorning in static types. Even as a type definition in a separate file it just feels wrong.

Ruby particularly is already strongly typed so there isn't too many suprises with automatic conversions or anything like that. RBS also just makes metaprogramming more annoying - and Ruby's ability to do metaprogramming easily is one of its biggest strengths in my opinion.

If I wanted a statically typed language I would just use a statically typed language.

tedivm• 10 months ago

I've been working with Python for years (since 2014) and typing makes the code less buggy and easier to maintain. I also would hardly call it "shoehorning", as years of design went into it.

Honestly the only people I see who really push back against it are the people who haven't bothered learning it. Once people use it for a bit, in my experience at least, they don't want to go back.

throwaway1063823• 10 months ago

Maybe it's just because Python is just kindof a lousy language to use in the first place. I started with Java and C++, did Python for a bit and switched to Ruby and never looked back. Being forced to use Python for anything feels like a punishment.

Years of design also went into Ruby's type system, and for the people that enjoy it - be my guest - but I would never use it for my own code.

vintagedave• 10 months ago

My permanent instructions to Claude are:

* Always strongly type, for local variables, method parameters, and return types

* Avoid Any unless absolutely required

* hasattr() and get() are often code smells; if the type can be known, use that type

* Use beartype for all methods.

I _love_ beartype and want to plug it to everyone on HN: https://github.com/beartype/beartype

I'm building my own coding agent, like Claude, and it is built with opinionated style. Strongly typing Python and using beartype are what it will try to do unless the user specifies otherwise.

lend000• 10 months ago

Not willingly, but it's a lost cause getting AI generated code to avoid it.

beebmam• 10 months ago

I just don't see why people use Python in the AI era. Statically typed languages help AI reason about code enormously during compilation.

pedrellimath• 10 months ago

Python is amazing for that reason. You choose whether you want to do it or not.

notatoad• 10 months ago

an underrated benefit of type hints is how much better my copilot autocompletions are on type hinted code.

rao-v• 10 months ago

I’d love to see an analysis of how much typing hurts LLMs that need to read / edit your code (due to increased context) vs helps (due to more clear type context).

I want to believe that corrected typed python code is easier for smaller models to generate / interact with, but who knows how the trade-offs actually work out.

_alternator_• 10 months ago

The reason to use type hints is simple: it vastly improves scalability, making LLM agents much less error prone. Try it: tell Claude to type hint every function (e.g., in your Claude.md file) and see how much easier it is to scale your agents.

This also works for humans, but many python programmers who learned python before type hints can't be bothered. :sad_panda:

dajonker• 10 months ago

A dynamic language with type hints has all of the disadvantages of a dynamic language with all the disadvantages of a static language on top of it.

amne• 10 months ago

Is it me or is everything slowly moving to strong types but don't want to commit?

For PHP it slowly got introduced in php5.4 and now it's expected to type hint everything and mark the file strict with linters complaining left and right that "you're doing a bad job by having mixed-type variables"

In Ruby you get Sorbet or RBS.

What is JavaScript? Oh, you mean TypeScript.

and so on ..

My take is that if you need strong types switch to a language with strong types so you can enjoy some "private static final Map<String, ImmutableList<AttemptType>> getAttemptsBatches(...)"

Python developers are embracing type hints

Related Stories