Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python’s “type hints” are a bit of a disappointment to me

uninformativ.de

Post reply on HN
Print view View original

61–70 of 597 posts

Re: Python’s “type hints” are a bit of a disappointment to me

#61

Post by pydry »

riyadparvez wrote: post #36
just-ok wrote: post #27

Despite this: > Even if the Python runtime did check all the type hints at runtime, then it would still be too late. I don’t want a fancy type exception at runtime. That already exists (most of the time). I want to know about type mismatches in advance. You should check out Typeguard [1], which lets you add a @type_checked decorator to anything and get runtime type checking that's far better than e.g. a random blowup…

There's also bear-type for runtime type checking: https://github.com/beartype/beartype .

I've been perplexed as to why this hasnt been built in to the python runtime since day 1.

Re: Python’s “type hints” are a bit of a disappointment to me

#62

Post by the_af »

throwaway81523 wrote: post #59
davidhariri wrote: post #37

Earlier quoted context omitted.

Fully agree with this. Type hinting (not checking) is idiomatic to Python. MyPy is a great way to enforce checking. It's great to have the option to use the hints for intellisense only.

I've found that even when I write code intended to be statically checked from the beginning, mypy often misses stuff. I was enthusiastic about mypy at first and I still use it, but I'm not sure at this point that it is worth it.

Same here. And I come from (and am a fan of) statically typed languages. The type hinting story for Python seems confusing and not completely useful to me.

Re: Python’s “type hints” are a bit of a disappointment to me

#63

Post by civilized »

ledauphin wrote: post #55
civilized wrote: post #44

Earlier quoted context omitted.

> not-very-educated thoughts on gradual typing This seems like an inaccurate and condescending put-down. What is the definition of "educated" in this context? Is there a book or generally well-known resource? The author is clearly thoughtful and curious. Near the top of the post he says "what I’m hoping for is that someone will come along and tell me that I got it all wrong. “When you do it as follows, the system wor…

This one is self-explanatory. Can a string be printed? Yes! Then Python is (correctly) allowing typesafe behavior here. Your (incorrect) annotation does not in any way contradict the typesafe-ness of printing a string (or an int). They're both equally printable. This is just a very, very bad example, plain and simple. It 'looks' bad to a superficial reading, but in practice it demonstrates only what is already known…

It seems that your point boils down to "Python enforces types at runtime if you define 'enforce types at runtime' not to include 'enforcing that data you declare to be of a certain type actually is of that type'".

Am I the only one baffled by this way of thinking?

Re: Python’s “type hints” are a bit of a disappointment to me

#64

Post by bb88 »

sirsinsalot wrote: post #32
jonathan-adly wrote: post #7

100% agree - never really understood the movement behind adding types to Python. Type hints are a useless complexity that yield little return. If you want types, use something else other than Python. The whole thesis behind Python is simple is better than complex.

I find it best to see type hinting as "living documentation". Yeah, you can ignore it, it is Python afterall, but if you want the IDE/tools to have better more helpful hints ... use machine readable hint documentation. I'd argue if your functions are full of type-assert like guards, _then_ use another language!

I just saw someone on Twitter post a "IntegerType" class which did exactly this, including capturing the sign -- because he couldn't trust int().

Re: Python’s “type hints” are a bit of a disappointment to me

#65

Post by the_af »

davidhariri wrote: post #37
daenz wrote: post #23

Opinions like these are frustrating because, although they make valid points, it comes off as "they didn't do 100% exactly what I want, so I'm not using them at all." With many tools, there is a middle ground between using them for everything, and not using them at all. Python's type hints is one of those tools. When I'm writing code, and a variable or signature is easy to annotate, I'll annotate it. And guess what?…

Fully agree with this. Type hinting (not checking) is idiomatic to Python. MyPy is a great way to enforce checking. It's great to have the option to use the hints for intellisense only.

Honest question: what's the point of type hinting without type checking?

I must be mistaken, but I always thought "type hinting" was a synonym of "optional type annotations". But if you're not using those annotations for actual type checking at some point, what are they good for?

Re: Python’s “type hints” are a bit of a disappointment to me

#66

Post by ImprobableTruth »

vesche wrote: post #11

I agree. I'm glad that they're optional. One of the main reasons to use Python is to prioritize development speed over performance AND to prioritize read/write-ability over hand jamming mundane syntax. I understand why some who have a background in typed languages might prefer to use Python with type hints, but it should be understood that they aren't very Pythonic.

Man, the idea that type hints reduce read-ability are crazy to me. It's like if someone told me that they think comments make code less readable.

Like, even if you think that type hints have ugly syntax, prior to them vast most projects just didn't bother with documenting the shape of data, so you had to read source code, guess and experiment. Unless you just don't care about knowing what you're specifically working with (which strikes me as living on the edge), how is it not an ergonomics gain?

Re: Python’s “type hints” are a bit of a disappointment to me

#67

Post by phailhaus »

Python's type system is a disappointment, but I don't think this article does a great job of explaining why. My biggest gripes:

1. There is no way to get typing like dataclasses without writing your own mypy plugin. The syntax is simply not expressive enough to do it. This means that if you want to be productive with a library like Pydantic, you also have to add the mypy plugin to your dependencies and add it to your mypy config. Otherwise, no typing.

2. You cannot compose types. There is no way to say "hey this type is the same as this dictionary here, except the keys are all optional." If you're trying to type a RESTful API, your only option is to repeat yourself and carefully keep all your types in sync.

3. To this day, there is still no way to express optional keys. Not "Optional" keys, but keys that can be left out of your dictionary. The closest you can get is this weird hack where you can set `total=False` in your TypedDict, which makes all keys optional.

I really wish Python learned from Typescript, but it's too late at this point. Too many half-baked measures have already made it into the spec.

Re: Python’s “type hints” are a bit of a disappointment to me

#68

Post by xarope »

I'm surprised there's no mention of pydantic or other type systems. I started with type hints, and find that the discipline of using types invaluable, especially when coding public API backends for which validation is a strong necessity, whether semi-static (ala mypy) or runtime.

Re: Python’s “type hints” are a bit of a disappointment to me

#69

Post by kstrauser »

ainar-g wrote: post #26
Lendal wrote: post #8

I tried mypy when I first started into type checking in Python back when I was trying to do Python in VS Code and I discovered that mypy is a time-sucking anti-productivity disaster that needs to die in a fire. When I started learning PyCharm though, I discovered that type checking can actually work well in Python and it is not a waste of time at all. So I advise people now that unless you're using PyCharm, do not wa…

Could you elaborate on mypy? I'm not a Python developer (and I really have much more experience with statically typed languages), but if I ever had to maintain a Python codebase, I'd assume that adding mypy and type annotations would be among the first things I'd do, so it's a bit of a surprise to read that.

I love mypy. It's fine, if sometimes a little alarming when you aim it at a previously-untyped codebase. In my case, it turned up plenty of type errors that probably never became a problem in production, but very well could've. It's also a nice thing to put in a CI pipeline to block new code errors.

Re: Python’s “type hints” are a bit of a disappointment to me

#70

Post by xarope »

the_af wrote: post #65
davidhariri wrote: post #37

Earlier quoted context omitted.

Fully agree with this. Type hinting (not checking) is idiomatic to Python. MyPy is a great way to enforce checking. It's great to have the option to use the hints for intellisense only.

Honest question: what's the point of type hinting without type checking ? I must be mistaken, but I always thought "type hinting" was a synonym of "optional type annotations". But if you're not using those annotations for actual type checking at some point , what are they good for?

as a reminder for yourself/others who need to read/maintain your code?

(I am often reminded of my perl days, where something I thought idiomatic 3 days ago, is now completely incomprehensible when I just want to make a minor change)

Post reply on HN