Live data from Hacker News

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

uninformativ.de

271–280 of 597 posts

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

#271
post #35

Don't let perfect be the enemy of good. Type hints are usefull especially in large codebases. I find myself using them with minimal effort and they can catch bugs that otherwise wouldn't be catched.

Totally agree. Mypy isn't perfect but it's so much better than no type annotations

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

#272
Types help to encourage readable code. If it's hard to add type annotations to a function then the function is too complicated. I've seen this with wildly polymorphic functions that needed dozens of overloads to properly type... which means that engineers need to hold all that complexity in their heads

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

#273
post #252

Earlier quoted context omitted.

Not with any TSC settings I've ever used.

noImplicitAny is a very common config option that helps catch a ton of bugs. I wouldn’t use TS without it.

noImplicitAny is different than what's being discussed (I think). Returning something typed as `any` in a function that has a different return type is totally fine: it's not implicit (you've cast it to any), and it passes (you're saying the type is literally anything after all).

There are lint rules to avoid typing as `any`.

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

#274

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…

> If you're using a dynamic language, then _by definition_ the language will not enforce your static hints at runtime.

I don't think this follows by definition. It's common not to check the static hints at runtime, but a dynamic language could choose to treat them as contracts or assertions. Over in Lisp-land, SBCL will enforce static type declarations at runtime [1], contrary to most other Lisp compilers, at least under the default compilation settings (you can force it to skip the checks by compiling with a low "safety" level). If the compiler can prove that a static type declaration always holds, it will omit the runtime check; otherwise it will compile it into a runtime assertion.

[1] http://www.sbcl.org/manual/#Declarations-as-Assertions

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

#275
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.

Code is way less readable without types. If I see this:

  def create_user(user):
    other_function(user)
Then how do I know what `user` is? Is it a dictionary? An object? If it's an object, where's its class definition? To find the answer I need to search for all the code that calls `create_user`, and then code that calls that code, and then code that calls that code, ad nauseam.

Onboarding into a huge, untyped codebase is brutal

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

#276
post #262

Earlier quoted context omitted.

The problem I see is that you are trying to peg a square in a round role and thinking that the square is at fault for not being flexible enough. Anyone that has seen the py2 -> py3 debacle will tell you that "let's make python static" is not something that could happen unless you are willing to rewrite the entire ecosystem of libraries and applications, and quite possibly upsetting the majority of current users who w…

I don't want to turn Python into a statically typed language. I think there's valid criticism to be made about the flaws of its type hinting (as does the article's author), and I cannot help but compare its usefulness to static type checking. I also cannot choose the language. I'm not in a position to choose languages at my current job; I seldom find myself in that position at any job.

We are going to go back in circles, but as I said in the very first comment: mypy is the tool you want [0]. It won't do everything, but progress has been steady and more and more projects are providing type libraries for it.

But given that your response to the mypy recommendation was to complain (it's slow, it doesn't catch everything) then it makes it difficult to acknowledge the "valid criticism"... as in: people are working on it, what else do you want?

[0] https://mypy.readthedocs.io/en/stable/existing_code.html

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

#277
I find it interesting how we have come full circle on static typing. When I was in University 2009-2013... and years leading up to it, dynamic typing was becoming the hot thing after years of Java/C/C++ dominance. Statically typed languages were looked down upon and talked about as being analogous to "Enterprise", "suit and tie" type soul crushing software development. We had people fulling in Ruby/Rails bandwagon, Java/C/C++ starting to become deprecated from university curriculum in favor of Python... JS starting to eat the front end and HN startups were talking about how they write their entire stack in a flavor of Lisp.

And now, just a few years later- Rust, Go are two of the hottest languages around, TypeScript is eating JavaScript, Python/Ruby have added static typing constructs, C# continues to do well in its niche and even Java of all languages has become somewhat cool again even though being Oracle product.

It's been an amazing transition to watch in action play out in front of my career, I can't even imagine those who have been in the industry for 30-40years who have probably been through a dozen of these cycles.

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

#278
post #6

I love type hints. They make the code so much more readable. I wish they could do more, but knowing what the programmer intended for a variable is huge. Now, when I see code without type hints I think, "Oh man, now I have to dig into everything to know what anything is."

Yeah. I usually don't bother with type hints for local variables, but for parameters and return types, it makes skimming old code so much easier.

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

#279
post #269

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…

Nice. How do you force types just in the new code?

You can pipe the diff into specific flake8 checkers. Disable the check by default so it's not run over the entire codebase, and have a separate line for running specific checks on just the diff. Eg:

git diff -U0 --relative origin/master... | flake8 --diff --select

I'll leave the flake8 plugin as an exercise to the reader as ours is intertwined with code I can't share right now.

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

#280
post #277

I find it interesting how we have come full circle on static typing. When I was in University 2009-2013... and years leading up to it, dynamic typing was becoming the hot thing after years of Java/C/C++ dominance. Statically typed languages were looked down upon and talked about as being analogous to "Enterprise", "suit and tie" type soul crushing software development. We had people fulling in Ruby/Rails bandwagon, J…

Give it a few more decades and maybe we'll come to accept a Hindley-Milner system of the 1970s, like that of Standard ML.

And maybe a few more decades after that to go back to the dynamic typing of the 1950s, like that of Common Lisp. :)

Post reply on HN