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

41–50 of 597 posts

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

#41

Post by dtech »

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…

It seems to me like Python needs to get Typescript's capabilities (if Python wants to go further this way of course). It solves all these problems very well, and has no problem with 2 and most of the author's objections.

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

#42

Post by Znafon »

zmgsabst wrote: post #40
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…

That’s the point though: Duck typing and heterogeneous dictionaries are (and have been) standard Python. Adding a type system which doesn’t respect duck typing by trying to access the member even when the types don’t match or which can’t express standard idioms used in Python seems a poor architectural choice. It’s not saying that Python’s type system is “too much discipline”, but rather that the type system doesn’t…

Python typing supports duck typing: https://peps.python.org/pep-0544/

and heterogeneously typed ducts: https://peps.python.org/pep-0589/

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

#43

Post by albertzeyer »

> 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 inspections only passes when there are no warnings.

Although, I have to admit, we explicitly exclude type warnings because here we have a couple of false positives. So in this respect, it actually agrees with the article.

But then we also do code review and there we are strict about having it all correct.

Yes, I see the argument of the article that the typing in Python is not perfect and you can easily fool it if you want, so you cannot 100% trust the types. But given good standard practice, it will only rarely happen that the type is not as expected and typing helps a lot. And IDE type warnings, or mypy checks still are useful tools and catch bugs for you, just not maybe 100% of all typing bugs but still maybe 80% of them or so.

> Isn’t it better to detect at least some errors than to detect none at all?

> You can not be sure that they are correct. As such, you must always treat them as if they were wrong.

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.

> They [type hints] waste mental energy when reading code

How? The author even acknowledges that you could just treat them as code comments if you like. By that argument, all code comments waste mental energy?

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

#44

Post by civilized »

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 works: $explanation” Because, you know, I’d really like to have static typing in Python."

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

And yet, the author points out that this is a working program:

  foo: int = 'hello'
  print(foo)
In what reasonable sense can Python be said to "enforce types at runtime" here?

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

#45

Post by Spivak »

Znafon wrote: post #42
zmgsabst wrote: post #40

Earlier quoted context omitted.

That’s the point though: Duck typing and heterogeneous dictionaries are (and have been) standard Python. Adding a type system which doesn’t respect duck typing by trying to access the member even when the types don’t match or which can’t express standard idioms used in Python seems a poor architectural choice. It’s not saying that Python’s type system is “too much discipline”, but rather that the type system doesn’t…

Python typing supports duck typing: https://peps.python.org/pep-0544/ and heterogeneously typed ducts: https://peps.python.org/pep-0589/

And you can make it work at runtime too! So as long as you have the right methods and attrs isinstance on your duck-typed object will return true!

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

#46

Post by ZoomZoomZoom »

> What I want is this: Some language that’s as easy to use as Python and it should be compiled and with good static typing...

Well, there's always Nim. [0]

> ...but it should also not be compiled because then it wouldn’t be as easy to use as Python anymore. Whoops?

Eh, there's Nimscript? [1]

0. https://nim-lang.org/

1. https://nim-lang.org/docs/nims.html

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

#47

Post by bb88 »

chis wrote: post #10

Only facts here. I think most large codebases eventually see type hints drift away from reality as individual contributors are more incentivized to hack in `Any` types to make things compile instead of typing every line properly. This is especially common for handling data objects which come in over the network - often they can have a couple different types but people just type it as one thing for simplicity. Overall…

My understanding was large python code bases (think Google) have a large problem. Someone makes a code change and suddenly it becomes difficult to find the scope of type errors in their monorepo. That was the driving force IIRC.

That said, I think pytype makes a lot of sense since it infers types from code, which you can edit by hand and then merge back into the python file when your code is stable.

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

#48

Post by [deleted] »

dgellow wrote: post #24
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…

If you use VSCode and Pylance (Microsoft python language server) you don’t need to setup Mypy, you can enable type checking in user settings and it will use its own engine for type analysis. You have two modes, basic and strict. I would recommend to try out if you can, the experience is quite good. I personally find “strict” too strict for the current state of python, but “basic” is already very helpful. The develope…

[deleted]

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

#49

Post by ImprobableTruth »

zmgsabst wrote: post #40
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…

That’s the point though: Duck typing and heterogeneous dictionaries are (and have been) standard Python. Adding a type system which doesn’t respect duck typing by trying to access the member even when the types don’t match or which can’t express standard idioms used in Python seems a poor architectural choice. It’s not saying that Python’s type system is “too much discipline”, but rather that the type system doesn’t…

No offense, but have you actually given it a shot? Duck typing is supported and you can get virtually all use cases of heterogenous dictionaries by using union types and duck typing. The article even touches on this.

edit: To be more precise: The article specifically mentions that accessing invalid members give you a type error, but posits that people will probably not bother and just use 'any' instead. How is that not saying 'too much discipline'?

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

#50

Post by ledauphin »

dtech wrote: post #41
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…

It seems to me like Python needs to get Typescript's capabilities (if Python wants to go further this way of course). It solves all these problems very well, and has no problem with 2 and most of the author's objections.

Typescript does absolutely fantastic type inference, which mypy definitely does not. I think that's a huge advantage for Typescript over mypy, and it's really foundational to the value it provides.

However, even in Typescript it is nontrivial to _annotate_ these complex types, and in most cases it's still possible to do in Python - you just need to commit to using something like dataclasses rather than pretending that what you have is a `dict`.

Basically, to get the most out of static typing in the world of Python, you do have to write more boilerplate than you would in Typescript, and in particular you need to avoid dicts and prefer various sorts of class-based data containers (again, dataclasses, attrs, namedtuples, etc).

Post reply on HN