Live data from Hacker News

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

uninformativ.de

451–460 of 597 posts

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

#451

Earlier quoted context omitted.

On the small scale, Python is very productive. Once you get to large codebases with a rotating roster of many developers, it becomes a net negative, which is why type specification languages are gaining major inroads. I love Python, but I wouldn't write anything for production at any scale in it anymore. But for small scale stuff, it remains my favorite! (Although, I like static binaries languages, like Go, for a lot…

What is "major inroads"? Python is actually rising in popularity and major companies are building big things entirely in Python... In my opinion there is no excuse not to.

Python has a tremendous amount of momentum because it has become so popular outside of the traditional software development world, but other languages are picking away at it, even given that momentum. And while I am in a bubble, like everyone else, in my bubble, and those I talk to in my bubble, all see large a shift away from Python.

Adding stronger typing, like type hints, could reverse that, of course.

The reason not to is performance and reliability. Typing helps with the latter, Python is just bad at the former.

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

#452
post #435

Earlier quoted context omitted.

What is "major inroads"? Python is actually rising in popularity and major companies are building big things entirely in Python... In my opinion there is no excuse not to.

What you both are experiencing is your bubbles clashing.

This is a rather uninteresting statement, as we all live in bubbles - knowledge of them helps, but really just puts you in a different bubble. Still a bubble.

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

#453
post #364

Earlier quoted context omitted.

> My stack is pycharm, mypy, pydantic, sqlalchemy stub, several mypy plugins, black, isort, tabNine completion, and a bunch of custom scripts/Make to automate the common tasks. Christ. What a mess. With a stack like that, it's a stretch to say you're "writing in Python" anymore.

> Most of their main arguments (...) evaporate as soon as you start using the correct tooling. You silly! Just use these carefully curated list of 28 different tools (that I got to after years of trial and error) and you'll have a somewhat acceptable tooling and type support in Python.

That list is an editor, a type checker, a package to enforce type checks at runtime, 3rd party type annotations for a popular SQL ORM, some plugins for the type checker (probably the pydantic one), a code formatter, an import sorter, and (optionally) a Github co-pilot alternative.

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

#454
post #89

Earlier quoted context omitted.

> The tooling that pays attention to type hints is slow as molasses or difficult to use or understand. I use mypy daily on big codebases, it is fine, not fast, but fine. > The type hints themselves are of dubious use. They tell you when you make type errors, they help you understand what type things should be. The same as in literally every other language with static typing. There is nothing special here, nothing dif…

> The same as in literally every other language with static typing No, obviously not the same, otherwise I wouldn't be complaining. They are not even on par with Typescript, which I'm not a fan of either. > [type hints] tell you when you make type errors Not according to other comments I seem to be getting here. Other people are arguing type hints are not primarily for checking , but a form of notation for documentat…

Better code completion and documentation in you editor is another great feature of type hinting

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

#455
post #432

Earlier quoted context omitted.

On the small scale, Python is very productive. Once you get to large codebases with a rotating roster of many developers, it becomes a net negative, which is why type specification languages are gaining major inroads. I love Python, but I wouldn't write anything for production at any scale in it anymore. But for small scale stuff, it remains my favorite! (Although, I like static binaries languages, like Go, for a lot…

What's your definition of "large codebases" here? My experience is that on Python codebases large (~100k lines) and small, type annotations are generally a net negative, particularly with a "rotating roster of many developers", because of their complexity and detrimental effect they have on readability. As the OP says, incorrect types are worse than no types at all.

type hinting is a bandaid, I'm not going defend it. My argument is that statically typed languages are better for large scale development.

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

#456

In my experience, people with less experience with object oriented programming will end up creating lots of objects only to create types. These objects have no business use case, nor do they aid in any encapsulation. These objects are made just to help typing. Nuts! Python type hinting is like moving backwards in time because the amount of time devs take to "hint", takes away the main reason for using python, that is…

This has to be a troll comment. The overhead of typing is literally _nothing_ compared to the amount of time it takes to sift through code to figure out a) what types a function/class accepts as arguments and b) what types are returned. If you don't check it then I agree it's useless. However, working with libraries that are typed is an _insane_ productivity boost over working with untyped libraries.

This is a snippet from the python codebase, written by a type nazi

SessionInfoType = Union[AuthzQuerySessionInfo, AuthnReqSessionInfo]

Notice how it is doing a union of two objects. Do you know what those 2 objects are? Those are types as well. They have no business use case.

AuthzQuerySessionInfo = TypedDict( "AuthzQuerySessionInfo", {"name_id": Any, "came_from": Any, "issuer": Any, "not_on_or_after": Any, "authz_decision_info": Any,}, total=False, )

AuthnReqSessionInfo = TypedDict( "AuthnReqSessionInfo", { "ava": Union[dict, None], "name_id": Any, "came_from": Any, "issuer": Text, "not_on_or_after": Union[int, bool], "authn_info": list, "session_index": Any, }, total=False, )

RequestCookieType = TypedDict( "RequestCookieType", { "request_id": Text, "came_from": Optional[Text], "public_id": Text, "is_mobile": Union[Literal[True], Text], "c_challenge": Text, "c_challenge_method": Text, }, total=False, )

So now. not only do we have dicts that represent above data, we also have TypedDicts created specially for types.

To rub salt on the wound, the callsite with these types now looks like

session_info = authresp.session_info() session_info = cast(SessionInfoType, session_info)

WTF!! If we have to see a codebase littered with TypedDicts just to satisfy type annotations and then have to cast everything to that type - why not just wrap it in a class and call it a day?

When I see garbage like this, I seriously question the productivity improvement brought about by python type annotations. I certainly end up spending an inordinate amount of time unraveling nested unions of types all over now. Considering switching to a team that uses Golang.

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

#457
The main problem with type hints for Python code is that it changes the way you think about writing Python.

Before, it went something like this:

1) Install Python (if you don't have it already)

2) Install your favorite text editor

3) Write some Python!

Now, it goes something like this:

1) Install Python

2) Install your favorite IDE

3) Install plugins for your IDE

4) Install black, mypy, flake8 plus some other nonsensical "helper" library

5) Don't forget your poetry, gotta have that

6) Be careful to pick only 3rd party libraries that have good type hints..

7) God help you if you try writing something yourself, let your IDE do that.

Type hints make not only your code more complicated and unreadable. They complicate your entire workflow.

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

#458
post #343

Earlier quoted context omitted.

As long as you don't have to rely on 3rd party libraries, sure, type hints are fine. Many popular libraries, however, don't have type hints or use them inconsistently (looking at you numpy, pytorch, tensorflow, scipy, ...). Always great fun to see function signatures that use type hints for the parameters and return Any . So it really depends what kind of code you write - web frameworks might be fine, data science an…

Type hints are good if you stick to the std + your own code that mostly relies on std. Otherwise, don't bother.

If you expect type hints to be perfect and completely disallow you to write type unsound code then this is right, if you expect type hints to be useful when developing then this is very wrong. The automatic type hints produced by pyright on completely untyped code are fantastic.

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

#459
post #326

This article is so hopelessly mis-informed, that it's practically hard to read without screaming "that's not how any of this works!" Most of their main arguments - type hints can be wrong, they can be ignored, and they don't inform you in a useful way about program state because of this - all evaporate as soon as you start using the correct tooling. My stack is pycharm, mypy, pydantic, sqlalchemy stub, several mypy p…

Python types just work. Just use these 30 libraries, spice up your IDE with settings and voila /s. This is garbage and moving backwards as a programmer. I loved python when it was easy to use with any editor and with few plugins. Now I'm just going to switch to a statically typed language where I don't have to install a zillion plugins to get first class typing.

Python type annotations in the language are nothing more then allowing you put any Python expression in the "type slot" and have it be syntatically valid. They don't do anything. All the functionality is 3rd party packages taking advantage of their existence.

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

#460
post #446

Adding type hints to Python has increased my productivity by at least a factor of 10. They allow you to reason about code in a local function without having to track back up dozens of call sites to ensure you're getting what you think you're getting. That alone is worth the price of admission. Both when editing code or reviewing someone else's. It's fantastic, particularly in a very large code base. The editor experi…

Why not just use a statically type language? I really don't understand why python is so popular outside of a few specialized areas.

Because ecosystems are what makes people productive and languages are just a means to access them. Python's ecosystem is absolutely massive and high-quality.
Post reply on HN