12 ms·

Python type hints may not be not for me in practice

98 points by ingve 2y ago

liontwist 2y ago
Python continues to show it will adopt any feature with online interest without guiding principle.
aegis4244 2y ago
Is that a double negative in your title ? Or is it an inside joke I didn't get ?
- DemocracyFTW2 2y ago
  You can't never have not enough of no good thing!
- thebigspacefuck 2y ago
  Ragebait title to get you to click it
- ahaferburg 2y ago
  I think it's a typo. The original title is "Python type hints may not be for me in practice". Dang, could you change it?
  - pansa2 2y ago
    The title of the article itself has been edited to remove the double negative
Hackbraten 2y ago
> yet another Python thing I'd have to try to keep in my mind despite it being months since I used them last. Typing hints are also a moving target: they have changed, sometimes significantly, on every minor Python release since they came to be. The `Optional` type came and went (being replaced by the new Union syntax.) Type classes are usually born in the `typing` module, then some of them get moved to `collections`, `abc`, or `collections.abc`. Some types have even been moved several times. `TypeAlias` came and went (replaced by `type`). `List` became `list`. `Tuple` became `tuple`. Forward declarations require a workaround by using string literals. But in Python 3.14, they no longer do, and the workaround will become deprecated. I'm an evangelist for static type checking, and I never write a Python function signature without complete typing annotations. I also think that typing annotations in Python are evolving in a good way. However, for long-lived Python scripts, I highly recommend that developers are aware of, and factor in, the effort necessary to keep up with the evolution of static typing across Python versions. That effort spent on migrating is going to come on top of the mental load that typing hints already add to your plate.
- maleldil 2y ago
  The old stuff never stopped working, though. You can still use Optional, Union, TypeAlias, and import collection protocols from typing. You don't have to migrate if you don't want to. They're not even deprecated.
  - Hackbraten 2y ago
    I encourage you to open the `typing` documentation [0] and search for the word `deprecated`. Spoiler alert: the search result will be three-figure. Some of the results are already scheduled for removal. [0]: https://docs.python.org/3/library/typing.html https://docs.python.org/3/library/typing.html
    - maleldil 2y ago
      This is the relevant bit: > The redundant types are deprecated as of Python 3.9. However, while the aliases may be removed at some point, removal of these aliases is not currently planned. As such, no deprecation warnings are currently issued by the interpreter for these aliases. The idea is that new code shouldn't use them, but they work perfectly fine and will keep working in the near future. Even if they decide to remove these at some point, you're looking at several years before it actually happens, and you'll have plenty of time to migrate. As it stands, you can use them to your heart's content without issues.
      - Hackbraten 2y ago
        Your quote only refers to a small part of the deprecations, i.e. deprecated type aliases. Deprecations that are not in that group do cause warnings, and some of them are already scheduled for removal. Your quote also conveniently left out the following paragraph: > The aliases are guaranteed to remain in the typing module without deprecation warnings until at least Python 3.14. Python 3.14 is less than a year away. > Even if they decide to remove these at some point, you're looking at several years before it actually happens, and you'll have plenty of time to migrate. I agree. I still think it adds to the pile of chores, especially for people who are on the fence anyway as to whether type annotations are worth the additional mental load to them.
BiteCode_dev 2y ago
That's why they are not unspecified to be optional.
andrewstuart 2y ago
Program the way you like it and it should be fun. If you are at work doing professional programming then typing helps avoid bugs and makes programming more of a reliable and robust process. But doing your own thing, doing little utilities, banging out quick stuff, do exactly what makes you happy. Programming should be fun not a chore and if types make it a chore for you then drop them.
agubelu 2y ago
Type hints are nice, until you have to interact with a library that isn't type-hinted, and then it very quickly becomes a mess. I don't know how other IDEs behave, but VScode + the Python extensions try to infer the missing hints and you end up with beauties such as `str | None | Any | Unknown`, which of course are completely meaningless. Even worse, the IDE marks as an error some code that is perfectly correct, because it somehow doesn't match those nonsensical hints. And so it gives you the worst of both worlds: a lot of false positives that you quickly learn to ignore, dooming the few actual type errors to irrelevance, because you'll ignore them anyways until they blow up at runtime, just as it'd happen without typehints.
- robjwells 2y ago
  Worst of both worlds is right. I came back to a Python project with a couple of critical but untyped dependencies recently after writing mostly Rust, and to clear up a large number of these (particularly “type is partially unknown”) I had the choice between lots of purely type-checking ceremony (`typing.cast`) or going without.
  - rrr_oh_man 2y ago
    What did you end up choosing & why?
    - robjwells 2y ago
      It's only a personal side project and I have a good handle on the untyped modules in question, so in the end I suppressed most of the errors with `# type:ignore` and friends. I'd reconsider that if I was doing more than the odd bug fix on the project. I still like Python, and started using type hints early, but there's enough added friction to make me question using them in the future. I imagine on big projects the benefit is clearer.
      - rrr_oh_man 2y ago
        Thanks for sharing! Asking because I was really, really annoyed by the non-helpfulness of the type hints in practice, contrary to the theory.
greatgib 2y ago
The logic of type hint is not bad but sadly I think that type hint are making python source code messy and unreadable. I'm missing a lot simple functions with explicit argument names and docstrings with arguments types and descriptions clearly but discreetly documented. It was one big strength of Python to have so simple and clean code without too much boilerplate. Also, I have the feeling that static typing extremist are trying to push the idea that type hinting allows to ensure to not mix types as it would be bad. But from my point of view the polymorphic and typing mixing aspect is a strong force of Python. Like having dictionaries that are able to hold whatever you want is so incredible when you compare to trying to do the equivalent in Java for example. One part where I find type hint to be wonderful still is for things like pydantic and dataclasses!
- Vampiero 2y ago
  > Like having dictionaries that are able to hold whatever you want is so incredible when you compare to trying to do the equivalent in Java for example. Can't you just make a dictionary of objects, same as in C#? Except that in C#, if you really want to, you can also use `dynamic` to get python-like behavior. Otherwise, generally speaking, in a strongly typed language you want to figure out what those objects have in common and put that inside an interface. If you can't modify those objects just slap an adapter pattern on top. The result is a dictionary of objects that adhere to a specific interface, which defines all the properties and procedures that are relevant to the domain and the problem. This makes thinking about the problem much easier from a type theoretical perspective because it lets you abstract away the concrete details of each object while preserving the fundamental aspects that you care about. I guess that it takes two different mindsets to in order to appreciate the pros and cons of dynamic vs static programming. There are certainly many pros for dynamic programming, but I'm more comfortable thinking about problems in generic terms where every relation and constraint is laid bare in front of me, one level removed from the actual implementation.
- Myrmornis 2y ago
  Python has union types, and you can type something as a container type with no type parameters.
KaiserPro 2y ago
Type hinting in python is a bit of a sticky plaster. We have pyre enforcement at work, the problem is, that it has been gradually turned on over time, so some stuff is pyre compliant (or just strategically ignored) and some stuff isnt, so when you open some old code to do something, you have a million errors to deal with. That would be fine if types were enforceable. in runtime type hinting does shit all. I would dearly love a "strict" mode where duck typing is turned off and variable are statically typed. However I suspect that will never happen, even though it'd speed up a load of stuff if done correctly (type inference happens a lot) I suspect to use type hints properly, I'd need to think a bit more C-like and create dataclasses as types to make things more readable, rather than using Dict[str,int] or what ever.
- zelphirkalt 2y ago
  There are some other ways of expressing names for types, once you start using typing. There are typevars, enums and using the "|" to separate options, there are TypedDict, NamedTuple, Union, Literal, Optional, and probably more. Not everything needs to be a dataclass.
sesuximo 2y ago
> PPS: I think my ideal type hint situation would be if I could create distinct but otherwise unconstrained types for things like function arguments and function returns, have mypy or other typing tools complain when I mixed them Cleaner/safer function args and return types is a common motivation for dataclass. has benefits over many/complex args besides typing too.
dzonga 2y ago
this is not a just a python problem but a problem in many dynamic languages. switching to the typed variants whether typecript, python type-hints, mypy etc will force you to do the dance to make the compiler happy instead of working on code. which is why for me - JSDoc is really good - it uses types for documentation and ends there.
tasn 2y ago
The Python type system is pretty bad, but it's still 100x better than not using types. We are heavy users of the (Rust) type system at Svix, and it's been a godsend. I wrote about it here https://www.svix.com/blog/strong-typing-hill-to-die-on/ https://www.svix.com/blog/strong-typing-hill-to-die-on/ We also use Python in some places, including the shitty Python type-system (and some cool hackery to make SQLAlchemy feel very typed and work nicely with Pydantic).
- youdontknowjuli 2y ago
  > (and some cool hackery to make SQLAlchemy feel very typed and work nicely with Pydantic). Sounds interesting. Can you elaborate on the cool hackery? We introduced SQLModel recently but struggle in a few cases (e.g. multi-level joins). Do you know reference projects for SQLAlchemy and pydantic?
  - tasn 2y ago
    My info is maybe a bit dated, as it's been a while since we wrote this hackery. We also adopted SQLModel at some point but we had to patch it to work well (I think some of my contributions are now in upstream). As for some of the hacks: def c(prop: t.Any) -> sa.Column: # type: ignore return prop To make it possible to access sqlmodel properties as columns for doing things like `in_` but still maintaining type safety. Added types ourselves to the base model like this: __table__: t.ClassVar[sa.Table] Added functions that help with typing like this: @classmethod async def _fetch_one(cls: t.Type[BaseT], db: BaseReadOnlySqlSession, query: Select) -> t.Optional[BaseT]: try: return (await db.execute(query)).scalar_one() except NoResultFound: return None and stuff like this for relationships: def ezrelationship( model: t.Type[T_], id_our: t.Union[str, sa.Column], # type: ignore id_other: t.Optional[t.Union[t.Any, sa.Column]] = None, # type: ignore ) -> T_: if id_other is None: id_other = model.id return sqlm.Relationship(sa_relationship=relationship(model, primaryjoin=f"foreign({id_our}) == {id_other}")) def ezrelationship_back( id_our: t.Union[str, sa.Column], # type: ignore id_other: t.Union[str, sa.Column], # type: ignore ) -> t.Any: model, only_id2 = id_other.split(".") return sqlm.Relationship( sa_relationship=relationship( model, primaryjoin=f"foreign({id_our}) == {id_other}_id", back_populates=only_id2, ) ) I hope this helps, I don't have time to find all the stuff, but we also hacked on SQLAlchemy a bit, and in other places.
travisgriggs 2y ago
I typehint the stuff that is easy. My observations about typehinting in Python track the 80:20 rule or even a 90:10 rule. You get about 80% benefit for typhinting the easy 20%.
truculent 2y ago
The problem (in my opinion) is that Python gives you the tools (and perhaps even encourages you) to write code that would benefit from typing. It's perfectly feasible to write maintainable, well-designed code in a dynamic language. I've worked with some extremely robust and ergonomic Clojure codebases before, for example. However, in Clojure, the language pushes you into its own "pit of success". Personally, I never feel that with Python.
- chamomeal 2y ago
  That’s good to hear about clojure! I just started learning the language and it’s been a ton of fun (especially babashka omg) but I’m so typescript-minded that it’s been really tough being back in dynamic land.
  - ethagnawl 2y ago
    Have you looked into core.spec at all? It's been a while since I've even thought about it but I believe it's an interesting middle ground between Python's type hints and TypeScript static typing. It functions as sort of verifiable documentation (at runtime, if you wish) and can also be used to dynamically generate data (e.g. for testing). I miss Clojure. EDIT: Here's a great talk Rich Hickey gave about it at LispNYC, which I was lucky enough to attend. https://youtu.be/dtGzfYvBn3w?feature=shared https://youtu.be/dtGzfYvBn3w?feature=shared
terminalbraid 2y ago
Sometimes I feel like we need an analog to javascript/typescript. Ptypethon if you will.
- ansgri 2y ago
  Absolutely. The main problem with python typing is that checking types is optional. A dialect with mandatory types (with inference) and runtime/load-time checking would be great.
  - IshKebab 2y ago
    Checking types is optional with Typescript too. We don't need another type annotation syntax for Python. The existing one is fine.
  - maleldil 2y ago
    Use pyright in strict mode, then. If you really want runtime checking, you can Pydantic's validation decorator, typeguard or beartype. Current typed python is much better than people give it credit. You just have to use it properly.
solarkraft 2y ago
It’s kind of cool that type hints can be reflected on to do things (see Pydantic). Other than that I find it pretty cumbersome to use in practice, coming from TypeScript. Semi-relatedly I also dislike Python’s different ways to access objects/dicts, it feels arbitrary and cumbersome.
thebigspacefuck 2y ago
This is what we ended up using with mypy so we could add type checks to our CI without having to fix every single typing error: https://github.com/orsinium-labs/mypy-baseline https://github.com/orsinium-labs/mypy-baseline
craftkiller 2y ago
> In writing this it occurs to me that I do often know that I have distinct types (for example, for what functions return) and I shouldn't mix them, but I don't want to specify their concrete shape as dicts, tuples, or whatever. [...] Type aliases are explicitly equivalent to their underlying thing, so I can't create a bunch of different names for eg typing.Any and then expect type checkers to complain if I mix them. It sounds to me like you're describing the NewType pattern which is just slightly farther down the page you linked in the article. https://docs.python.org/3/library/typing.html#newtype https://docs.python.org/3/library/typing.html#newtype
scoofy 2y ago
My objection to strong types in python is philosophical. Python mimics natural language, and natural language rejects strong types for context resolved ambiguity. In the way we resolve these issues in natural language, we can resolve bugs in python, that is, “do you mean integer ’3’ or string’3’” instead of insisting we define everything always forever. To me, people who use type hinting are just letting me know they have written code that doesn’t check in line.
- orf 2y ago
  Python has always been strongly typed, since the very beginning. The article and the feature has nothing to do with strong types.
- stoperaticless 2y ago
  Strong/weak types and static/dynamic typing are orthogonal things. Strong type system limits things like 1+”1”. Static type system requires type declarations (“int i”). Python always had strong dynamic types.
- maleldil 2y ago
  > people who use type hinting are just letting me know they have written code that doesn’t check in line. Yes, that's the point. We use typing so the type checker can find the mistakes for us instead of adding `isinstance` everywhere.
aSanchezStern 2y ago
The thing that the author says they would prefer is already in Python, it's called NewType (https://docs.python.org/3/library/typing.html#typing.NewType https://docs.python.org/3/library/typing.html#typing.NewType) They say "...so I can't create a bunch of different names for eg typing.Any and then expect type checkers to complain if I mix them." `MyType = NewType('MyType', Any)` is how you do this. At the end, they suggest a workflow: "I think my ideal type hint situation would be if I could create distinct but otherwise unconstrained types for things like function arguments and function returns, have mypy or other typing tools complain when I mixed them, and then later go back to fill in the concrete implementation details of each type hint" That's just doing the above, but then changing the `NewType('MyType', Any)` to something like `NewType('MyType', list[dict[str, int]])` later when you want to fill in the concrete implementation.
- stavros 2y ago
  This is great, thank you for this. I've always wanted something that would complain if I passed Meters to something expecting Feet, but aliases didn't consider this an error.
  - cmcconomy 2y ago
    You should look into the pint library if you want full unit support!
    - stavros 2y ago
      That looks really useful, thank you! I don't always specifically want units, but it'll be great for when I do!
- Der_Einzige 2y ago
  Why is it that many of the examples for the "typing.protocal" class right below this involve meth??? Python WTF?
  - rnewme 2y ago
solidsnack9000 2y ago
It seems like the author is looking for the ability to specify types as `typeof <function>:arguments` and `typeof <function>:return`. I can see how this could make prototyping easier. It is also helpful for cases (not uncommon in Python) where you're just proxying another function.
- deleted 2y ago
  [deleted]
- throwitaway1123 2y ago
  TypeScript has the equivalent of what you're describing via the `Parameters` and `ReturnType` utility types [1][2], and I've found these types indispensable. So you can do the following: type R = ReturnType<typeof someFunction> type P = Parameters<typeof someFunction> [1] https://www.typescriptlang.org/docs/handbook/utility-types.html#parameterstype https://www.typescriptlang.org/docs/handbook/utility-types.h... [2] https://www.typescriptlang.org/docs/handbook/utility-types.html#returntypetype https://www.typescriptlang.org/docs/handbook/utility-types.h...
  - solidsnack9000 2y ago
    Yeah, now that you mention it, I remember using it a lot when I worked more in that language.
- 1_1xdev1 2y ago
  Like `ParamSpec`?
  - maleldil 2y ago
    ParamSpec doesn't have the same objective as what they're saying. The sibling comment shows how you can get the proper types in TypeScript and use them as types for other functions. On the other hand, ParamSpec is a hack to properly forward function argument types to decorators.
Neywiny 2y ago
The note about creating your own data types is interesting. I used to be heavily dependent on tuples. Admittedly dicts would've saved me here but I liked the efficiency of numeric indexing. Anyway, any time I changed ordering or anything I'd have countless headaches. I started using dataclasses and never looked back. I love turning the type checker on in vscode and seeing it correctly catch future issues. Only problem is when libraries are indirectly hinted, as others have pointed out
joeyagreco 2y ago
> After the code has stabilized I can probably go back to write type hints [...] but I'm not sure that this would provide very much value. I think most developers who revisit their projects 6+ months later would disagree with the second part of this statement. My typical flow for "quick scripts" is: on first pass I'll add basic type hints (typing ":str" after a func param takes .2 seconds) for more complex data structures (think a json response from an api), dict (or typing.Dict) work fine if you want a Python project to be maintainable, type hints are a requirement imho.
- VagabundoP 2y ago
  Considering that most AI add-ons type hint code reasonably well, there no real reason not to, just for readability. It takes a few seconds to prompt and then check it.
- kstrauser 2y ago
  That’s basically my approach and attitude, too. I was skeptical at first but I’d never go back to undecorated code. Paired with a decent language server, it’s soooo much easier writing correct code now.
- sa-code 2y ago
  And when I inherit a code base with no type hints asking an LLM to have a go at adding type hints also takes no time at all
- gikkman 2y ago
  This is my approach too. A kind of "relaxed" typing I often call it. Just knowing what a function expects and returns helps a lot, what each element of a tuple is, or what a list contains. Before type hints, I used to not enjoy Python at all, but these days I find it fun. The few times I spend time pondering about how to type things are greatly outweighed by the time saved of not having to research what type a particular variable is.
- never_inline 2y ago
  > for more complex data structures (think a json response from an api), dict (or typing.Dict) work fine One of the reason I use typing is IDE completion and error highlighting. For that purpose - I make sure to annotate even the obvious primitive types and for API responses, I find that defining a Pydantic model works very well.
4ad 2y ago
> Types prevent me from writing code that I don't understand. Yes, thats the point.
maleldil 2y ago
Something I didn't see mentioned much here is refactoring. Refactoring without types is like walking in the dark. You have to check everywhere to see how your changes impact other code, and you'll certainly miss some and only find out in production. With typing, when you change your type signature, you can just run the checker and get a list of places you need to change.
- chamomeal 2y ago
  Yeah to me this is the biggest difference between static/dynamic types. I mean there are a LOT of differences DX-wise, but refactoring is so scary without static types. If we need to make changes to the DB at work, I’ll just update the prisma schema and run ‘npx prisma generate’ followed by ‘tsc —noEmit’ to instantly see all the affected areas. I feel like there are a lot of similar little superpowers you get by having a nice static type system.
maxbond 2y ago
I think TypeScript provides a lot more of the freedom the author is looking for. For instance, you can say, "the type of this argument is whatever is returned by that function." Personally I find myself more comfortable and productive using types. Stating your types has a similar benefit to journaling, in my view. It's a forcing function for clarifying your ideas about the problem domain. Some perceive this as overhead, I perceive this as front loading. If my ideas are murky, I will run into trouble sooner or later. The later it is, the more painful it will be. I think it largely comes down to different habits of working and thinking. I don't think one way is superior to another inherently (though types are important for collaboration), but that different people work in different ways.
emeryberger 2y ago
I agree that writing type hints can be painful, especially if you are starting with a large code base that is mostly untyped. You might consider using RightTyper (https://github.com/RightTyper/RightTyper https://github.com/RightTyper/RightTyper) - basically run your Python 3.12+ program with it, and it will add type hints to your code. It’s fast, basically automatic, and by design RightTyper avoids overfitting to your types, letting a type checker like MyPy surface edge cases. In effect, the type checker becomes an anomaly detector (Full disclosure, I am one of the authors of RightTyper.) From the GitHub page: RightTyper is a Python tool that generates types for your function arguments and return values. RightTyper lets your code run at nearly full speed with almost no memory overhead. As a result, you won't experience slow downs in your code or large memory consumption while using it, allowing you to integrate it with your standard tests and development process. By virtue of its design, and in a significant departure from previous approaches, RightTyper only captures the most commonly used types, letting a type checker like mypy detect possibly incorrect type mismatches in your code.
- joshdavham 2y ago
  Why is your GitHub organization’s logo, the AWS logo?
  - emeryberger 2y ago
    In addition to being a faculty member at UMass Amherst, I am an Amazon Scholar, working at Amazon Web Services, where this work was conducted.
    - ycombinatrix 2y ago
      how come it isn't hosted under the official aws organization? https://github.com/aws https://github.com/aws
      - emeryberger 2y ago
        Can’t honestly remember the details! But it’s very much an AWS-owned org.
pansa2 2y ago
The biggest issue with Python type hints for me isn't the hints themselves, it's that they encourage people to write overly complex, verbose code just to satisfy the type checker. Code like this [0] could simply be 3 functions. Instead it's 3 classes, plus a base class `AstNode`, just so the author can appease the type checker by writing `body: List[AstNode]` instead of the dynamically-typed `body = []`. [0] https://gist.github.com/sportsracer/16a1e294966cfba83ba61e6a876d2222 https://gist.github.com/sportsracer/16a1e294966cfba83ba61e6a...
- dikei 2y ago
  That code looks like a proper object-oriented design to me, nothing to do with type-hints actually.
  - pansa2 2y ago
    Type hints encourage this sort of object-oriented design though, in my experience. The resulting code is extremely verbose compared to Pythonic "executable pseudocode". For example, see Jack Diederich's talk "Stop Writing Classes": https://www.youtube.com/watch?v=o9pEzgHorH0 https://www.youtube.com/watch?v=o9pEzgHorH0
    - maxbond 2y ago
      That talk had a big impact on my coding style. But citing a 99 line script written as an example for a blog post doesn't really support your argument. 99 lines is short, and verbosity is expected in such example code. Consider FastAPI. It uses functions as endpoints, like flask. Very compatible with "Stop Writing Classes." It also leverages type hinting to eliminate boilerplate and create more concise code. You don't have to put validation or dependency injection logic at the top of every endpoint, it's handled for you so you can dedicate screen space to the problems you're solving. Consider also the pythonism, "explicit is better than implicit." If memory serves, "Stop Writing Classes" wasn't so much about not writing containers for data but not writing containers for behavior when it wasn't associated with data. Behavior can live as a freestanding function just as well as inside of an object. But it's difficult to understand the semantics of freestanding nontrivial data, like dictionaries or long tuples. Dataclasses and pydantic models require a minimum of boilerplate and couple the data with it's semantic meaning, so that it's preserved across boundaries. I for one am never going back to the Python before these tools.
linsomniac 2y ago
Similar to the author, I infrequently write Python code (though I have a long history with it), but I feel quite the opposite about type hints. A few specific comments: - The LLMs can really help with typing tricky situations. If your editor can't already tell you what to use, asking an LLM usually can give me the answer. - Type annotations for code that might change is a lifesaver, because when I change it later on I now get a bunch of conflicts where I've used it using the old way. - Feel free to add annotations where it makes sense and is easy, and if something doesn't make sense or it is too hard to figure out the right type, you can skip it and still gain the benefits of using it elsewhere. - Annotations don't "force you to think about types", you already are thinking about types. They let you think a bit less about types I would argue, because they're documented in function calls and returns. "Can I read() from input_file, or do I need to open()read()?" "input_file:Path" makes it better documented, without encoding the object type in the name. I'm coming up on 30 years of using Python, and I never really missed typing, but honestly I write basically all of my new code with annotations because of the IDE benefits I get from it. I love that the Python implementation allows me to get the benefits without forcing it on me. In my distant past I very much loved coding in C, but was quite happy with Python's lack of strict typing. This feels like a good middle-ground.
ethagnawl 2y ago
This post title gives me a headache.
whinylittleb 2y ago
[flagged]
adsweedler 2y ago
If you could snap your fingers and have your type hints update to match your code, it wouldn’t get in the way of your work. Hyperbolically: You have to be able to edit code at the speed of thought - whatever it takes - or else programming languages cease to be a more useful tool than just thinking. If you type slower than you think, or can’t do the type-hint-based textual translation as quickly as you think, then… yeah - it’s not good for you. The advice I’d wanna hear for myself is: just get better. But the advice I’d give to my coworkers is: have explicit domains where you’re able to do whatever is most efficient and effective, and then when you hand off data to the next subsystem - obey a contract. A schema. Be that type hints or a .proto file or a database schema or an API. Doesn’t matter.
gorgoiler 2y ago
The same applies to tests, maybe docs too. For x in tests, type annotations, and documentation*: If you write your x first then you have to decide what your API is. This is great if you want to think about your API. Sometimes though you just want to get down to it and play around with a new idea. Either way is fine. As soon as you start sharing code or patching production code or patching someone else’s production code, one must insist on seeing some kind of x. Having x around the outside of a system — rather than requiring x be added throughout the entire system — is often good enough. *The useful, architecture kind.
nmca 2y ago
The problems with python types are: A) The type system is fairly bad, as type systems go (forgivable) B) the type checkers are, for large codebases, excruciatingly slow, to the point that the tests are faster!! The second is not forgivable.
danjl 2y ago
This has all happened before. This will all happen again. Everyone felt the same way about TypeScript. Types feel annoying at first, if you lived without them. Using untyped libraries is annoying until they all have types, which happens over time. Types prove their worth every time.
bmitc 2y ago
It takes mere seconds to write type hints, and with modern auto-complete tooling or Copilot, it's basically automatic. It goes a long way to use tools like MyPy to verify your code and also provide documentation for users of your code. If you don't want to write type hints, don't use a dynamically typed language.
est 2y ago
IMHO, type hints should only serve two purposes: 1. design a memory layout for faster execution 2. press dot and get suggestions in IDE other usage of types brings more problem than it solves.
deleted 2y ago
[deleted]
propagate97 2y ago
Doesn't know how the first two things about python type hints. Must be shit. Great article...
- dcgudeman 2y ago
  honestly, that's how I read this article. Not sure why so many people seem to be agreeing with him... I guess it speaks to the general understanding about how to use python type hints

98 points by ingve 2y ago

liontwist 2y ago

Python continues to show it will adopt any feature with online interest without guiding principle.

aegis4244 2y ago

Is that a double negative in your title ? Or is it an inside joke I didn't get ?

DemocracyFTW2 2y ago
You can't never have not enough of no good thing!
thebigspacefuck 2y ago
Ragebait title to get you to click it
ahaferburg 2y ago
I think it's a typo. The original title is "Python type hints may not be for me in practice". Dang, could you change it?
- pansa2 2y ago
  The title of the article itself has been edited to remove the double negative

Hackbraten 2y ago

> yet another Python thing I'd have to try to keep in my mind despite it being months since I used them last. Typing hints are also a moving target: they have changed, sometimes significantly, on every minor Python release since they came to be. The `Optional` type came and went (being replaced by the new Union syntax.) Type classes are usually born in the `typing` module, then some of them get moved to `collections`, `abc`, or `collections.abc`. Some types have even been moved several times. `TypeAlias` came and went (replaced by `type`). `List` became `list`. `Tuple` became `tuple`. Forward declarations require a workaround by using string literals. But in Python 3.14, they no longer do, and the workaround will become deprecated. I'm an evangelist for static type checking, and I never write a Python function signature without complete typing annotations. I also think that typing annotations in Python are evolving in a good way. However, for long-lived Python scripts, I highly recommend that developers are aware of, and factor in, the effort necessary to keep up with the evolution of static typing across Python versions. That effort spent on migrating is going to come on top of the mental load that typing hints already add to your plate.

maleldil 2y ago
The old stuff never stopped working, though. You can still use Optional, Union, TypeAlias, and import collection protocols from typing. You don't have to migrate if you don't want to. They're not even deprecated.
- Hackbraten 2y ago
  I encourage you to open the `typing` documentation [0] and search for the word `deprecated`. Spoiler alert: the search result will be three-figure. Some of the results are already scheduled for removal. [0]: https://docs.python.org/3/library/typing.html https://docs.python.org/3/library/typing.html
  - maleldil 2y ago
    This is the relevant bit: > The redundant types are deprecated as of Python 3.9. However, while the aliases may be removed at some point, removal of these aliases is not currently planned. As such, no deprecation warnings are currently issued by the interpreter for these aliases. The idea is that new code shouldn't use them, but they work perfectly fine and will keep working in the near future. Even if they decide to remove these at some point, you're looking at several years before it actually happens, and you'll have plenty of time to migrate. As it stands, you can use them to your heart's content without issues.
    - Hackbraten 2y ago
      Your quote only refers to a small part of the deprecations, i.e. deprecated type aliases. Deprecations that are not in that group do cause warnings, and some of them are already scheduled for removal. Your quote also conveniently left out the following paragraph: > The aliases are guaranteed to remain in the typing module without deprecation warnings until at least Python 3.14. Python 3.14 is less than a year away. > Even if they decide to remove these at some point, you're looking at several years before it actually happens, and you'll have plenty of time to migrate. I agree. I still think it adds to the pile of chores, especially for people who are on the fence anyway as to whether type annotations are worth the additional mental load to them.

BiteCode_dev 2y ago

That's why they are not unspecified to be optional.

andrewstuart 2y ago

Program the way you like it and it should be fun. If you are at work doing professional programming then typing helps avoid bugs and makes programming more of a reliable and robust process. But doing your own thing, doing little utilities, banging out quick stuff, do exactly what makes you happy. Programming should be fun not a chore and if types make it a chore for you then drop them.

agubelu 2y ago

Type hints are nice, until you have to interact with a library that isn't type-hinted, and then it very quickly becomes a mess. I don't know how other IDEs behave, but VScode + the Python extensions try to infer the missing hints and you end up with beauties such as `str | None | Any | Unknown`, which of course are completely meaningless. Even worse, the IDE marks as an error some code that is perfectly correct, because it somehow doesn't match those nonsensical hints. And so it gives you the worst of both worlds: a lot of false positives that you quickly learn to ignore, dooming the few actual type errors to irrelevance, because you'll ignore them anyways until they blow up at runtime, just as it'd happen without typehints.

robjwells 2y ago
Worst of both worlds is right. I came back to a Python project with a couple of critical but untyped dependencies recently after writing mostly Rust, and to clear up a large number of these (particularly “type is partially unknown”) I had the choice between lots of purely type-checking ceremony (`typing.cast`) or going without.
- rrr_oh_man 2y ago
  What did you end up choosing & why?
  - robjwells 2y ago
    It's only a personal side project and I have a good handle on the untyped modules in question, so in the end I suppressed most of the errors with `# type:ignore` and friends. I'd reconsider that if I was doing more than the odd bug fix on the project. I still like Python, and started using type hints early, but there's enough added friction to make me question using them in the future. I imagine on big projects the benefit is clearer.
    - rrr_oh_man 2y ago
      Thanks for sharing! Asking because I was really, really annoyed by the non-helpfulness of the type hints in practice, contrary to the theory.

greatgib 2y ago

The logic of type hint is not bad but sadly I think that type hint are making python source code messy and unreadable. I'm missing a lot simple functions with explicit argument names and docstrings with arguments types and descriptions clearly but discreetly documented. It was one big strength of Python to have so simple and clean code without too much boilerplate. Also, I have the feeling that static typing extremist are trying to push the idea that type hinting allows to ensure to not mix types as it would be bad. But from my point of view the polymorphic and typing mixing aspect is a strong force of Python. Like having dictionaries that are able to hold whatever you want is so incredible when you compare to trying to do the equivalent in Java for example. One part where I find type hint to be wonderful still is for things like pydantic and dataclasses!

Vampiero 2y ago
> Like having dictionaries that are able to hold whatever you want is so incredible when you compare to trying to do the equivalent in Java for example. Can't you just make a dictionary of objects, same as in C#? Except that in C#, if you really want to, you can also use `dynamic` to get python-like behavior. Otherwise, generally speaking, in a strongly typed language you want to figure out what those objects have in common and put that inside an interface. If you can't modify those objects just slap an adapter pattern on top. The result is a dictionary of objects that adhere to a specific interface, which defines all the properties and procedures that are relevant to the domain and the problem. This makes thinking about the problem much easier from a type theoretical perspective because it lets you abstract away the concrete details of each object while preserving the fundamental aspects that you care about. I guess that it takes two different mindsets to in order to appreciate the pros and cons of dynamic vs static programming. There are certainly many pros for dynamic programming, but I'm more comfortable thinking about problems in generic terms where every relation and constraint is laid bare in front of me, one level removed from the actual implementation.
Myrmornis 2y ago
Python has union types, and you can type something as a container type with no type parameters.

KaiserPro 2y ago

Type hinting in python is a bit of a sticky plaster. We have pyre enforcement at work, the problem is, that it has been gradually turned on over time, so some stuff is pyre compliant (or just strategically ignored) and some stuff isnt, so when you open some old code to do something, you have a million errors to deal with. That would be fine if types were enforceable. in runtime type hinting does shit all. I would dearly love a "strict" mode where duck typing is turned off and variable are statically typed. However I suspect that will never happen, even though it'd speed up a load of stuff if done correctly (type inference happens a lot) I suspect to use type hints properly, I'd need to think a bit more C-like and create dataclasses as types to make things more readable, rather than using Dict[str,int] or what ever.

zelphirkalt 2y ago
There are some other ways of expressing names for types, once you start using typing. There are typevars, enums and using the "|" to separate options, there are TypedDict, NamedTuple, Union, Literal, Optional, and probably more. Not everything needs to be a dataclass.

sesuximo 2y ago

> PPS: I think my ideal type hint situation would be if I could create distinct but otherwise unconstrained types for things like function arguments and function returns, have mypy or other typing tools complain when I mixed them Cleaner/safer function args and return types is a common motivation for dataclass. has benefits over many/complex args besides typing too.

dzonga 2y ago

this is not a just a python problem but a problem in many dynamic languages. switching to the typed variants whether typecript, python type-hints, mypy etc will force you to do the dance to make the compiler happy instead of working on code. which is why for me - JSDoc is really good - it uses types for documentation and ends there.

tasn 2y ago

The Python type system is pretty bad, but it's still 100x better than not using types. We are heavy users of the (Rust) type system at Svix, and it's been a godsend. I wrote about it here https://www.svix.com/blog/strong-typing-hill-to-die-on/ https://www.svix.com/blog/strong-typing-hill-to-die-on/ We also use Python in some places, including the shitty Python type-system (and some cool hackery to make SQLAlchemy feel very typed and work nicely with Pydantic).

youdontknowjuli 2y ago
> (and some cool hackery to make SQLAlchemy feel very typed and work nicely with Pydantic). Sounds interesting. Can you elaborate on the cool hackery? We introduced SQLModel recently but struggle in a few cases (e.g. multi-level joins). Do you know reference projects for SQLAlchemy and pydantic?
- tasn 2y ago
  My info is maybe a bit dated, as it's been a while since we wrote this hackery. We also adopted SQLModel at some point but we had to patch it to work well (I think some of my contributions are now in upstream). As for some of the hacks: def c(prop: t.Any) -> sa.Column: # type: ignore return prop To make it possible to access sqlmodel properties as columns for doing things like `in_` but still maintaining type safety. Added types ourselves to the base model like this: __table__: t.ClassVar[sa.Table] Added functions that help with typing like this: @classmethod async def _fetch_one(cls: t.Type[BaseT], db: BaseReadOnlySqlSession, query: Select) -> t.Optional[BaseT]: try: return (await db.execute(query)).scalar_one() except NoResultFound: return None and stuff like this for relationships: def ezrelationship( model: t.Type[T_], id_our: t.Union[str, sa.Column], # type: ignore id_other: t.Optional[t.Union[t.Any, sa.Column]] = None, # type: ignore ) -> T_: if id_other is None: id_other = model.id return sqlm.Relationship(sa_relationship=relationship(model, primaryjoin=f"foreign({id_our}) == {id_other}")) def ezrelationship_back( id_our: t.Union[str, sa.Column], # type: ignore id_other: t.Union[str, sa.Column], # type: ignore ) -> t.Any: model, only_id2 = id_other.split(".") return sqlm.Relationship( sa_relationship=relationship( model, primaryjoin=f"foreign({id_our}) == {id_other}_id", back_populates=only_id2, ) ) I hope this helps, I don't have time to find all the stuff, but we also hacked on SQLAlchemy a bit, and in other places.

travisgriggs 2y ago

I typehint the stuff that is easy. My observations about typehinting in Python track the 80:20 rule or even a 90:10 rule. You get about 80% benefit for typhinting the easy 20%.

truculent 2y ago

The problem (in my opinion) is that Python gives you the tools (and perhaps even encourages you) to write code that would benefit from typing. It's perfectly feasible to write maintainable, well-designed code in a dynamic language. I've worked with some extremely robust and ergonomic Clojure codebases before, for example. However, in Clojure, the language pushes you into its own "pit of success". Personally, I never feel that with Python.

chamomeal 2y ago
That’s good to hear about clojure! I just started learning the language and it’s been a ton of fun (especially babashka omg) but I’m so typescript-minded that it’s been really tough being back in dynamic land.
- ethagnawl 2y ago
  Have you looked into core.spec at all? It's been a while since I've even thought about it but I believe it's an interesting middle ground between Python's type hints and TypeScript static typing. It functions as sort of verifiable documentation (at runtime, if you wish) and can also be used to dynamically generate data (e.g. for testing). I miss Clojure. EDIT: Here's a great talk Rich Hickey gave about it at LispNYC, which I was lucky enough to attend. https://youtu.be/dtGzfYvBn3w?feature=shared https://youtu.be/dtGzfYvBn3w?feature=shared

terminalbraid 2y ago

Sometimes I feel like we need an analog to javascript/typescript. Ptypethon if you will.

ansgri 2y ago
Absolutely. The main problem with python typing is that checking types is optional. A dialect with mandatory types (with inference) and runtime/load-time checking would be great.
- IshKebab 2y ago
  Checking types is optional with Typescript too. We don't need another type annotation syntax for Python. The existing one is fine.
- maleldil 2y ago
  Use pyright in strict mode, then. If you really want runtime checking, you can Pydantic's validation decorator, typeguard or beartype. Current typed python is much better than people give it credit. You just have to use it properly.

solarkraft 2y ago

It’s kind of cool that type hints can be reflected on to do things (see Pydantic). Other than that I find it pretty cumbersome to use in practice, coming from TypeScript. Semi-relatedly I also dislike Python’s different ways to access objects/dicts, it feels arbitrary and cumbersome.

thebigspacefuck 2y ago

This is what we ended up using with mypy so we could add type checks to our CI without having to fix every single typing error: https://github.com/orsinium-labs/mypy-baseline https://github.com/orsinium-labs/mypy-baseline

craftkiller 2y ago

> In writing this it occurs to me that I do often know that I have distinct types (for example, for what functions return) and I shouldn't mix them, but I don't want to specify their concrete shape as dicts, tuples, or whatever. [...] Type aliases are explicitly equivalent to their underlying thing, so I can't create a bunch of different names for eg typing.Any and then expect type checkers to complain if I mix them. It sounds to me like you're describing the NewType pattern which is just slightly farther down the page you linked in the article. https://docs.python.org/3/library/typing.html#newtype https://docs.python.org/3/library/typing.html#newtype

scoofy 2y ago

My objection to strong types in python is philosophical. Python mimics natural language, and natural language rejects strong types for context resolved ambiguity. In the way we resolve these issues in natural language, we can resolve bugs in python, that is, “do you mean integer ’3’ or string’3’” instead of insisting we define everything always forever. To me, people who use type hinting are just letting me know they have written code that doesn’t check in line.

orf 2y ago
Python has always been strongly typed, since the very beginning. The article and the feature has nothing to do with strong types.
stoperaticless 2y ago
Strong/weak types and static/dynamic typing are orthogonal things. Strong type system limits things like 1+”1”. Static type system requires type declarations (“int i”). Python always had strong dynamic types.
maleldil 2y ago
> people who use type hinting are just letting me know they have written code that doesn’t check in line. Yes, that's the point. We use typing so the type checker can find the mistakes for us instead of adding `isinstance` everywhere.

aSanchezStern 2y ago

The thing that the author says they would prefer is already in Python, it's called NewType (https://docs.python.org/3/library/typing.html#typing.NewType https://docs.python.org/3/library/typing.html#typing.NewType) They say "...so I can't create a bunch of different names for eg typing.Any and then expect type checkers to complain if I mix them." `MyType = NewType('MyType', Any)` is how you do this. At the end, they suggest a workflow: "I think my ideal type hint situation would be if I could create distinct but otherwise unconstrained types for things like function arguments and function returns, have mypy or other typing tools complain when I mixed them, and then later go back to fill in the concrete implementation details of each type hint" That's just doing the above, but then changing the `NewType('MyType', Any)` to something like `NewType('MyType', list[dict[str, int]])` later when you want to fill in the concrete implementation.

stavros 2y ago
This is great, thank you for this. I've always wanted something that would complain if I passed Meters to something expecting Feet, but aliases didn't consider this an error.
- cmcconomy 2y ago
  You should look into the pint library if you want full unit support!
  - stavros 2y ago
    That looks really useful, thank you! I don't always specifically want units, but it'll be great for when I do!
Der_Einzige 2y ago
Why is it that many of the examples for the "typing.protocal" class right below this involve meth??? Python WTF?
- rnewme 2y ago

solidsnack9000 2y ago

It seems like the author is looking for the ability to specify types as `typeof <function>:arguments` and `typeof <function>:return`. I can see how this could make prototyping easier. It is also helpful for cases (not uncommon in Python) where you're just proxying another function.

deleted 2y ago
[deleted]
throwitaway1123 2y ago
TypeScript has the equivalent of what you're describing via the `Parameters` and `ReturnType` utility types [1][2], and I've found these types indispensable. So you can do the following: type R = ReturnType<typeof someFunction> type P = Parameters<typeof someFunction> [1] https://www.typescriptlang.org/docs/handbook/utility-types.html#parameterstype https://www.typescriptlang.org/docs/handbook/utility-types.h... [2] https://www.typescriptlang.org/docs/handbook/utility-types.html#returntypetype https://www.typescriptlang.org/docs/handbook/utility-types.h...
- solidsnack9000 2y ago
  Yeah, now that you mention it, I remember using it a lot when I worked more in that language.
1_1xdev1 2y ago
Like `ParamSpec`?
- maleldil 2y ago
  ParamSpec doesn't have the same objective as what they're saying. The sibling comment shows how you can get the proper types in TypeScript and use them as types for other functions. On the other hand, ParamSpec is a hack to properly forward function argument types to decorators.

Neywiny 2y ago

The note about creating your own data types is interesting. I used to be heavily dependent on tuples. Admittedly dicts would've saved me here but I liked the efficiency of numeric indexing. Anyway, any time I changed ordering or anything I'd have countless headaches. I started using dataclasses and never looked back. I love turning the type checker on in vscode and seeing it correctly catch future issues. Only problem is when libraries are indirectly hinted, as others have pointed out

joeyagreco 2y ago

> After the code has stabilized I can probably go back to write type hints [...] but I'm not sure that this would provide very much value. I think most developers who revisit their projects 6+ months later would disagree with the second part of this statement. My typical flow for "quick scripts" is: on first pass I'll add basic type hints (typing ":str" after a func param takes .2 seconds) for more complex data structures (think a json response from an api), dict (or typing.Dict) work fine if you want a Python project to be maintainable, type hints are a requirement imho.

VagabundoP 2y ago
Considering that most AI add-ons type hint code reasonably well, there no real reason not to, just for readability. It takes a few seconds to prompt and then check it.
kstrauser 2y ago
That’s basically my approach and attitude, too. I was skeptical at first but I’d never go back to undecorated code. Paired with a decent language server, it’s soooo much easier writing correct code now.
sa-code 2y ago
And when I inherit a code base with no type hints asking an LLM to have a go at adding type hints also takes no time at all
gikkman 2y ago
This is my approach too. A kind of "relaxed" typing I often call it. Just knowing what a function expects and returns helps a lot, what each element of a tuple is, or what a list contains. Before type hints, I used to not enjoy Python at all, but these days I find it fun. The few times I spend time pondering about how to type things are greatly outweighed by the time saved of not having to research what type a particular variable is.
never_inline 2y ago
> for more complex data structures (think a json response from an api), dict (or typing.Dict) work fine One of the reason I use typing is IDE completion and error highlighting. For that purpose - I make sure to annotate even the obvious primitive types and for API responses, I find that defining a Pydantic model works very well.

4ad 2y ago

> Types prevent me from writing code that I don't understand. Yes, thats the point.

maleldil 2y ago

Something I didn't see mentioned much here is refactoring. Refactoring without types is like walking in the dark. You have to check everywhere to see how your changes impact other code, and you'll certainly miss some and only find out in production. With typing, when you change your type signature, you can just run the checker and get a list of places you need to change.

chamomeal 2y ago
Yeah to me this is the biggest difference between static/dynamic types. I mean there are a LOT of differences DX-wise, but refactoring is so scary without static types. If we need to make changes to the DB at work, I’ll just update the prisma schema and run ‘npx prisma generate’ followed by ‘tsc —noEmit’ to instantly see all the affected areas. I feel like there are a lot of similar little superpowers you get by having a nice static type system.

maxbond 2y ago

I think TypeScript provides a lot more of the freedom the author is looking for. For instance, you can say, "the type of this argument is whatever is returned by that function." Personally I find myself more comfortable and productive using types. Stating your types has a similar benefit to journaling, in my view. It's a forcing function for clarifying your ideas about the problem domain. Some perceive this as overhead, I perceive this as front loading. If my ideas are murky, I will run into trouble sooner or later. The later it is, the more painful it will be. I think it largely comes down to different habits of working and thinking. I don't think one way is superior to another inherently (though types are important for collaboration), but that different people work in different ways.

emeryberger 2y ago

I agree that writing type hints can be painful, especially if you are starting with a large code base that is mostly untyped. You might consider using RightTyper (https://github.com/RightTyper/RightTyper https://github.com/RightTyper/RightTyper) - basically run your Python 3.12+ program with it, and it will add type hints to your code. It’s fast, basically automatic, and by design RightTyper avoids overfitting to your types, letting a type checker like MyPy surface edge cases. In effect, the type checker becomes an anomaly detector (Full disclosure, I am one of the authors of RightTyper.) From the GitHub page: RightTyper is a Python tool that generates types for your function arguments and return values. RightTyper lets your code run at nearly full speed with almost no memory overhead. As a result, you won't experience slow downs in your code or large memory consumption while using it, allowing you to integrate it with your standard tests and development process. By virtue of its design, and in a significant departure from previous approaches, RightTyper only captures the most commonly used types, letting a type checker like mypy detect possibly incorrect type mismatches in your code.

joshdavham 2y ago
Why is your GitHub organization’s logo, the AWS logo?
- emeryberger 2y ago
  In addition to being a faculty member at UMass Amherst, I am an Amazon Scholar, working at Amazon Web Services, where this work was conducted.
  - ycombinatrix 2y ago
    how come it isn't hosted under the official aws organization? https://github.com/aws https://github.com/aws
    - emeryberger 2y ago
      Can’t honestly remember the details! But it’s very much an AWS-owned org.

pansa2 2y ago

The biggest issue with Python type hints for me isn't the hints themselves, it's that they encourage people to write overly complex, verbose code just to satisfy the type checker. Code like this [0] could simply be 3 functions. Instead it's 3 classes, plus a base class `AstNode`, just so the author can appease the type checker by writing `body: List[AstNode]` instead of the dynamically-typed `body = []`. [0] https://gist.github.com/sportsracer/16a1e294966cfba83ba61e6a876d2222 https://gist.github.com/sportsracer/16a1e294966cfba83ba61e6a...

dikei 2y ago
That code looks like a proper object-oriented design to me, nothing to do with type-hints actually.
- pansa2 2y ago
  Type hints encourage this sort of object-oriented design though, in my experience. The resulting code is extremely verbose compared to Pythonic "executable pseudocode". For example, see Jack Diederich's talk "Stop Writing Classes": https://www.youtube.com/watch?v=o9pEzgHorH0 https://www.youtube.com/watch?v=o9pEzgHorH0
  - maxbond 2y ago
    That talk had a big impact on my coding style. But citing a 99 line script written as an example for a blog post doesn't really support your argument. 99 lines is short, and verbosity is expected in such example code. Consider FastAPI. It uses functions as endpoints, like flask. Very compatible with "Stop Writing Classes." It also leverages type hinting to eliminate boilerplate and create more concise code. You don't have to put validation or dependency injection logic at the top of every endpoint, it's handled for you so you can dedicate screen space to the problems you're solving. Consider also the pythonism, "explicit is better than implicit." If memory serves, "Stop Writing Classes" wasn't so much about not writing containers for data but not writing containers for behavior when it wasn't associated with data. Behavior can live as a freestanding function just as well as inside of an object. But it's difficult to understand the semantics of freestanding nontrivial data, like dictionaries or long tuples. Dataclasses and pydantic models require a minimum of boilerplate and couple the data with it's semantic meaning, so that it's preserved across boundaries. I for one am never going back to the Python before these tools.

linsomniac 2y ago

Similar to the author, I infrequently write Python code (though I have a long history with it), but I feel quite the opposite about type hints. A few specific comments: - The LLMs can really help with typing tricky situations. If your editor can't already tell you what to use, asking an LLM usually can give me the answer. - Type annotations for code that might change is a lifesaver, because when I change it later on I now get a bunch of conflicts where I've used it using the old way. - Feel free to add annotations where it makes sense and is easy, and if something doesn't make sense or it is too hard to figure out the right type, you can skip it and still gain the benefits of using it elsewhere. - Annotations don't "force you to think about types", you already are thinking about types. They let you think a bit less about types I would argue, because they're documented in function calls and returns. "Can I read() from input_file, or do I need to open()read()?" "input_file:Path" makes it better documented, without encoding the object type in the name. I'm coming up on 30 years of using Python, and I never really missed typing, but honestly I write basically all of my new code with annotations because of the IDE benefits I get from it. I love that the Python implementation allows me to get the benefits without forcing it on me. In my distant past I very much loved coding in C, but was quite happy with Python's lack of strict typing. This feels like a good middle-ground.

ethagnawl 2y ago

This post title gives me a headache.

whinylittleb 2y ago

[flagged]

adsweedler 2y ago

If you could snap your fingers and have your type hints update to match your code, it wouldn’t get in the way of your work. Hyperbolically: You have to be able to edit code at the speed of thought - whatever it takes - or else programming languages cease to be a more useful tool than just thinking. If you type slower than you think, or can’t do the type-hint-based textual translation as quickly as you think, then… yeah - it’s not good for you. The advice I’d wanna hear for myself is: just get better. But the advice I’d give to my coworkers is: have explicit domains where you’re able to do whatever is most efficient and effective, and then when you hand off data to the next subsystem - obey a contract. A schema. Be that type hints or a .proto file or a database schema or an API. Doesn’t matter.

gorgoiler 2y ago

The same applies to tests, maybe docs too. For x in tests, type annotations, and documentation*: If you write your x first then you have to decide what your API is. This is great if you want to think about your API. Sometimes though you just want to get down to it and play around with a new idea. Either way is fine. As soon as you start sharing code or patching production code or patching someone else’s production code, one must insist on seeing some kind of x. Having x around the outside of a system — rather than requiring x be added throughout the entire system — is often good enough. *The useful, architecture kind.

nmca 2y ago

The problems with python types are: A) The type system is fairly bad, as type systems go (forgivable) B) the type checkers are, for large codebases, excruciatingly slow, to the point that the tests are faster!! The second is not forgivable.

danjl 2y ago

This has all happened before. This will all happen again. Everyone felt the same way about TypeScript. Types feel annoying at first, if you lived without them. Using untyped libraries is annoying until they all have types, which happens over time. Types prove their worth every time.

bmitc 2y ago

It takes mere seconds to write type hints, and with modern auto-complete tooling or Copilot, it's basically automatic. It goes a long way to use tools like MyPy to verify your code and also provide documentation for users of your code. If you don't want to write type hints, don't use a dynamically typed language.

est 2y ago

IMHO, type hints should only serve two purposes: 1. design a memory layout for faster execution 2. press dot and get suggestions in IDE other usage of types brings more problem than it solves.

deleted 2y ago

[deleted]

propagate97 2y ago

Doesn't know how the first two things about python type hints. Must be shit. Great article...

dcgudeman 2y ago
honestly, that's how I read this article. Not sure why so many people seem to be agreeing with him... I guess it speaks to the general understanding about how to use python type hints