Hacker News Reader

Comment by mrln | Hacker News Reader

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

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

> hoping for an Unknown someday

Wouldn't that just be `object` in Python?

No, because the type checker should prevent you interacting with `Unknown` until you tie it down, but `object` is technically a valid type

Exactly, I want it to complain if I try to manipulate the fields/methods of an unknown object.

By default, Mypy warns you if try to reassign a method of any object[1]. It will also warn you when you access non-existent attributes[2]. So if you have a variable typed as `object`, the only attributes you can manipulate without the type checker nagging are `__doc__`, `__dict__`, `__module__`, and `__annotations__`. Since there are very few reasons to ever reassign or manipulate these attributes on an instance, I think the `object` type gets us pretty darn close to an "unknown" type in practice.

There was a proposal[3] for an unknown type in the Python typing repository, but it was rejected on the grounds that `object` is close enough.

[1]: https://mypy.readthedocs.io/en/stable/error_code_list.html#c...

[2]: https://mypy.readthedocs.io/en/stable/error_code_list.html#c...

[3]: https://github.com/python/typing/issues/1835

Thanks, I didn't have this context. I'll start using this!

In my opinion the sheer volume of "close enough" choices is what ruins Python's type system.

It's "close enough" to a usable type system that it's worth using, but it's full of so many edge cases and so many situations where they decided that it would be easier if they forced programmers to try and make reality match the type system rather than the type system match reality.

No wonder a lot of people in the comments here say they don't use it...

I think they can get away with the "close enough" solutions since Python's type annotations don't have any runtime contracts by default. Might be off-putting to people who are more familiar with statically typed languages (though not always, in my experience).

I would buy that argument more if Typescript didn't exist.

You can live with the "close enough" if you're writing a brand new greenfield project and you prevent anyone from ever checking in code mypy doesn't like and also don't use any libraries that mypy doesn't like (and also don't make web requests to APIs that return dictionary data that mypy doesn't like)

Retrofitting an existing project however is like eating glass.

That's what I use it for. If you type something as `object`, static type checkers can just narrow down the exact typing later.

> List, Duct, Tuple...

I'm aware this is just a typo but since a lot of the Python I write is in connection with Airflow I'm now in search of a way to embrace duct typing.

I am glad they improved this but I still like Optional[], and to a lesser extent, Union[]. It's much more readable to have Optional[str] compared to str | None.

I disagree with `Optional`. It can cause confusion in function signatures, since an argument typed as "optional" might still be required if there is no default value. Basically I think the name is bad, it should be `Nullable` or something.

I believe Python's own documentation also recommends the shorthand syntax over `Union`. Linters like Pylint and Ruff also warn if you use the imported `Union`/`Optional` types. The latter even auto-fixes it for you by switching to the shorthand syntax.

Option is a pretty common name for this, as is Maybe.[^1] Either way I think that ship is sailed in Python.

[^1]: https://en.wikipedia.org/wiki/Option_type

Reply on news.ycombinator.com