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

171–180 of 597 posts

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

#171

Post by ModernMech »

This is the kind of thing that happens when a language that used to be niche starts gaining more widespread use. People from other languages come along and want the niceties they enjoy to exist in the new language they are learning. The same thing happened to JavaScript; it used to just be a browser language for running scripts, and then it turned into a server side language with a module system and everything else. There were a lot of growing pains involved in that transition.

Now people who use other languages are coming to Python and thinking "Wouldn't it be great if..." and that's how Python the language is going to evolve. But we're going to have to go through this interim phase of awkward adolescence before type annotations mature as a feature.

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

#172

Post by ImprobableTruth »

zmgsabst wrote: post #111
ImprobableTruth wrote: post #49

Earlier quoted context omitted.

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

Yep — I use mixed annotations on my Python code because as the person I’m responding to pointed out, they catch many small type errors. Dataclasses have been awesome. I’m also generally pro-types, but I think it’s worth having a discussion about this type system in the context of Pythonisms. - - - - - If you’re using “any” for most of your types, then it’s not providing value — an untyped statement implicitly has the…

Sure, but the idea behind gradual typing is that 'Any' should only be temporary. IMO if you're serious about it, stable code should at least pass strict type checking, if not completely forbid even explicit Any.

>There’s a reason I brought up the JSON example: loading and manipulating JSON of varying structure is something I do a lot at work.

Do you have a specific example that you find troublesome? For JSON with a fixed, regular structure (i.e. no subtyping) something like Pydantic works well, otherwise using unions + protocols with custom validation code has covered even my most esoteric use cases so far.

If we're talking about unstable JSON, a recursive union type works well enough in my experience, though defining that type gets a bit ugly if your type checker doesn't directly support recursive types.

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

#173

Post by nas »

ledauphin wrote: post #121
the_af wrote: post #98

Earlier quoted context omitted.

Sorry, I wasn't clear: I want command-line tooling for the build pipeline, not for the IDE or any individual developer.

mypy is quite fast at the command line. certainly fast enough for CI usage, where speed is generally less critical than in an IDE.

Use "dmypy", it is fast.

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

#175

Post by linsomniac »

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…

Python can't be said to enforce types at runtime. AFAIK, it doesn't say that. In fact, the original article starts off with "I'm expecting to be able to run a static analyzer", then it goes on to say "This isn't caught at runtime".

Yes, but is it caught at static analyzer run? Yes, I typed it into vi and ran mypy on it and it said "error: Incompatible types in assignment (expression has type "str", variable has type "int")."

But I didn't have to run mypy on it, my editor told me: "Expression of type "Literal['hello']" cannot be assigned to declared type "int"".

Maybe the word "educated" wasn't the right choice in this case, can you offer a better one? I honestly couldn't make it through the entire article, despite several attempts. It is full of inconsistencies and what seem like wilful misunderstandings to justify the authors conclusion.

Particularly as the author starts off saying "run a static analysis tool" as if knowing that's how you go about it, and then saying "it doesn't catch it at runtime".

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

#176

Post by Bedon292 »

sevensor wrote: post #157
simonw wrote: post #153

"You don’t know if there really is a tool in place to check them." Every project I interact with that uses type hints runs mypy as part of CI - and I can see that they're setup to do that by looking at the CI configuration (which these days is usually done using GitHub Actions). I wouldn't add type hints to a project without also configuring mypy for it.

Precisely. We don't merge unless the result passes mypy.

We use pre-commit and you can't even commit until it passes mypy. It can be a bit frustrating sometimes, but overall it has saved us from a lot of issues.

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

#177

Post by the_af »

rglullis wrote: post #168
the_af wrote: post #151

Earlier quoted context omitted.

You get me wrong: my coworkers struggle to see the point of testing at all. Usually they can be sold on the path of maximum-reward-for-minimum-effort. Hard to enforce/check type hints are not it (they seem like busywork for no actual payoff). With statically typed languages, the ROI would be different: they would either get the thing to compile, or they wouldn't and leave the job. This sounds drastic but it's really…

> How else will the language improve then? That question hides the assumption that static languages are always an improvement over dynamic ones, when in reality we should think as different species that have adapted to fit into different environments. > We can improve the tooling and train the team with better practices though. "Better practices" are what makes you team more productive, not just blindly copying what…

> That question hides the assumption that static languages are always an improvement over dynamic ones, when in reality we should think as different species that have adapted to fit into different environments.

Let me give you a twofold answer to this.

1. I do think statically typed languages are generally better than dynamic languages for most use cases (with a few exceptions). I don't expect to convince you or anyone else of this. It may even be the case that I'm mistaken about this, but I made my mind after years of experience with both kinds of languages.

2. The alleged hidden assumption is not truly important. One should always criticize flawed features of any language, static or dynamic, and the answer should never be "well, choose another language". How else will languages improve if nobody is working on addressing their pain points?

> "Better practices" are what makes you team more productive, not just blindly copying what other people are doing. If your colleagues really believe that automated tests/type checking are not worth the effort, you are not going to convince them by saying "but so-and-so said otherwise". What you can do is ask for their pain points, and see if the tooling can help with it.

I'm both nodding in agreement and finding it very hard to think of something I said that made you think I disagreed with this.

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

#178

Post by evrydayhustling »

simonw wrote: post #153

"You don’t know if there really is a tool in place to check them." Every project I interact with that uses type hints runs mypy as part of CI - and I can see that they're setup to do that by looking at the CI configuration (which these days is usually done using GitHub Actions). I wouldn't add type hints to a project without also configuring mypy for it.

Yes. The reason type checking is separate from the interpreter is that python is an ecosystem, not a language. Even if you like static typing, 99% of projects benefit from other code that lacks typing. Type hinting puts you in control of where types are enforced while allowing you to use duck-typed code. The cost is that you have an extra step in your build chain - but CI, IDEs and other automation all but negate that cost.

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

#179

Post by Bedon292 »

Diggsey wrote: post #161
simonw wrote: post #153

"You don’t know if there really is a tool in place to check them." Every project I interact with that uses type hints runs mypy as part of CI - and I can see that they're setup to do that by looking at the CI configuration (which these days is usually done using GitHub Actions). I wouldn't add type hints to a project without also configuring mypy for it.

I work on a project that uses type hints but not mypy. To be fair, we used to use mypy, but there was just too much code that it couldn't check (sqlalchemy models, schematics models, some custom models, essentially lots of different data-modelling types!) Maybe it's improved since then, but it just wasn't mature enough at the time. However, type annotations still make the code so much easier to work with, because the…

There are still a lot of libraries without hints, so mypy has to be told to ignore them in the setup.cfg file. Last I checked, sqlalchemy still isn't so good with mypy. So we have it ignored. But mypy is still great overall.

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

#180

Post by linsomniac »

Honestly, I've recently written a few 300-500 line programs in Python using type hints and I'm never going back. And I'm not even using mypy often, if ever.

My editor now has a fairly deep understanding of my code, and can tell me of all sorts of surprising errors I'm making before I run the code. There have been a few times where I found an error, went into the editor and saw I had missed a error message about that line. Shout out: Using LunarVim with LSP and TreeSitter.

The other thing I'm enjoying is that libraries can use them to make things happen more automatically. I believe it was Typer (the CLI argument parsing library) where if you declare an argument to a function as "files: List[Path]", it understands that the argument will take one or more files, or "-" to mean stdin. If you just say "file: Path", it understands it is a singular file.

I was curious about type hints when they first came out, wasn't really expecting to use them but they seemed cool, but now I'm totally sold.

Post reply on HN