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

101–110 of 597 posts

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

#101

Post by the_af »

ledauphin wrote: post #76
civilized wrote: post #63

Earlier quoted context omitted.

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?

Python does and always has enforced types at runtime. This is called duck-typing. If you're not familiar with the concept of strong+dynamic, it is easy to see how this could be confusing. This may help. https://stackoverflow.com/questions/2351190/static-dynamic-v... Static type annotations by definition are not enforced at runtime. This has been true of every language that has ever used static typing, including C, C+…

> Yes, it is possible to annotate types in Python incorrectly. It's possible to do this in all other languages that allow type-unsafe behavior (whether natively or via reflection, etc). This may be less common in some languages than in others, but it is fundamentally possible in the vast majority of languages that perform static typing, because those types are fundamentally enforced at analysis time, not runtime.

It is pretty damn hard to make this mistake in languages that enforce static typing. I mean, you would have to go out of your way to do so. In Python, however, it is trivial to write the wrong type signature or to modify the body of a function so that it no longer matches the signature.

"Fundamentally possible but terribly unlikely, as opposed to the Python way of doing it" would be a more accurate description.

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

#102

Post by nomel »

the_af wrote: post #84
the__alchemist wrote: post #81

Earlier quoted context omitted.

The IDE catches type errors, and it lets you do things like simulate structs using @dataclass.

I wish the tooling outside IDEs worked better. There's obviously some magic going on with tools like PyCharm and VSCode + plugins. I wish this was the case with command line tools I can plug into the build/deploy pipeline. I know they exist, it's just they are unsatisfying and there are lots of cases where they miss stuff that is trivial to catch in statically typed languages.

As someone who lives in an IDE, I don't understand this. Trying to get all of the functionality of the default IDE, along with the trivially added plugins, to work in a visually digestible and sane way would be a curses nightmare of 30 command line tools. If you made it so they played well together, where a human could interpret what they were seeing, you would have something indistinguishable from an IDE.

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

#103

Post by ImprobableTruth »

civilized wrote: post #44
ledauphin wrote: post #20

this article is so full of... not-very-educated thoughts on gradual typing in a dynamic language that it's hard to know where to start. A few concrete criticisms: 1. If you're using a dynamic language, then _by definition_ the language will not enforce your static hints at runtime. However, good news! Python has always been strongly typed, and _does_ enforce types at runtime! 2. A number of the examples given would b…

> 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…

I think the top comment was less polite than it should be, but I would echo that the post seems to have a bit of a weird understanding of gradual typing?

The Any type is to allow incremental typing. You start out with dynamic code, and progressively 'typify' it by adding more and more annotations, with Any working as a stopgap where for the moment no valid type exists, until you finally have a fully typed program. Inserting Anys because you're lazy is like casting things to Object in Java because you're lazy, abusing it like that is just incredibly sloppy and bad code.

If someone is really struggling with this, simply use a linting rule to ban Any in 'mature' code.

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

#104

Post by throwaway81523 »

albertzeyer wrote: post #43

> Just the type hints were wrong. > warnings of IDEs are simple to ignore This is unusual. In my experience, of codebases I have worked with or have seen, when there are type hints, there are almost all perfectly correct. Also, you can setup the CI to check also for IDE warnings. For example, we use this script for PyCharm: https://github.com/rwth-i6/returnn/blob/master/tests/pycharm... The test for PyCharm inspectio…

> I don't get this argument. Isn't this the case for all other code as well? Most code has not been formally verified to work 100% correct. So you assume always all code is wrong? This doesn't make sense.

It isn't that you have to assume the code is wrong (you always have to assume that code is wrong). It's that even though you write type hints and they pass mypy, you still have to assume that the code has type errors. That is, mypy doesn't rigorously check that the program's types match its annotations. It only approximately checks that.

In (some) other languages, the type checker is 100% sound, so if your program passes type checking, you can be completely sure that the types all match. Opportunities for the code to be wrong are thus limited to mismatches between the types and the desired behaviour.

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

#105

Post by mirashii »

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.

I actually find that mypy is pretty weak and lacking, even within the python ecosystem. pyright seems to do a much better job at the type checking portion of things.

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

#106

Post by the_af »

nomel wrote: post #102
the_af wrote: post #84

Earlier quoted context omitted.

I wish the tooling outside IDEs worked better. There's obviously some magic going on with tools like PyCharm and VSCode + plugins. I wish this was the case with command line tools I can plug into the build/deploy pipeline. I know they exist, it's just they are unsatisfying and there are lots of cases where they miss stuff that is trivial to catch in statically typed languages.

As someone who lives in an IDE, I don't understand this. Trying to get all of the functionality of the default IDE, along with the trivially added plugins, to work in a visually digestible and sane way would be a curses nightmare of 30 command line tools. If you made it so they played well together, where a human could interpret what they were seeing, you would have something indistinguishable from an IDE.

I find your opinion baffling to be honest.

It's simply not true. Every statically typed language works like I described. Even Typescript works like this. You can have your IDE plugins, but you definitely don't need them to perform type checks. It's not true this requires "a nightmare of 30 command line tools", you just need one: the type checker (built into the language in most statically typed languages, but sometimes split into a separate tool).

Besides, your IDE doesn't live in the build pipeline (in your CI/CD tool). So you cannot rely on it.

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

#107

Post by hoosieree »

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?

Just a couple hours ago, a student asked me what was the type of a parameter in a function I wrote.

A type hint would have answered their question immediately (as they were reading the code).

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

#108

Post by fluster »

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?

I view them as similar to python's "private" functions, which are really just functions starting with an underscore. The interpreter will let anyone call them like any other function, but the general rule is don't do it, unless you know what you're doing and are willing to deal with the internals changing.

Python typing is like that. If I say a function takes a List[int], but you know I'm just calling a for loop, you can ignore it and hand me a Set[int]. Maybe it breaks some day, but you're allowed to take that risk, if you have a need.

Do either of these things do anything comments couldn't? Not really. But they're ways of indicating intended semantics without formally documenting your stuff, and when most of what you use the language for is scripts, that's actually pretty helpful. People actually use type hints in a way they didn't with comments, and that's caused a major improvement in code readability. Or at least that's been my experience

You can absolutely look at all this and say python's a crazy, terrible language you never want to touch, but if you've got no choice on language for whatever reason, or you're throwing something together and don't feel like writing `private static final synchronized` forty time, type hints are great.

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

#109

Post by the_af »

rglullis wrote: post #96
the_af wrote: post #73

Earlier quoted context omitted.

So is it simply a standardized comment then? I will have a really bad time convincing my team mates, if that's the case. It's especially bad because, like any comment, it can say one thing but the code may do something different (actually happened to me).

You can have mypy doing the type checking . Just put it on your CI pipeline alongside your tests.

I know because I tried setting it up. It's slow, requires too much babysitting, and fails to catch cases.

In my experience, it just doesn't work cleanly out of the box like in true statically typed languages, and so I get pushback from my coworkers, who simply can't see the point. And I can't blame them.

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

#110

Post by rurp »

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?

They are useful for catching issue before code is committed or deployed. At my work we run mypy as part of our test suite, so failing type checks will block a merge or deploy.
Post reply on HN