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

161–170 of 597 posts

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

#161

Post by Diggsey »

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 they serve as documentation and are understood by the IDE. When I hit "." I actually get correct autocompletion because of the type annotations. When I want to know what a function returns I don't need to dig through multiple levels of function calls.

The article seems to be suggesting that because the type annotations might be wrong that they are worthless, which seems like a ridiculous argument. Any documentation can be wrong, but clearly having documentation that is 99% accurate is better than not having it at all.

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

#162

Post by gorgoiler »

I never liked how go makes you fix all your types before letting you run a program.

Suppose I wanted to hack something up and run it, just as a new idea? Maybe change a library function that is called in 20 places, but I only want to test it in one call site. Nope! Go forces you to polish up your turd of an idea in all 20 call sites before you can see that your algorithm / model / refactoring is nonsense. If you back out of the idea then all that turd polishing was a waste of time.

The mypy-python workflow, on the other hand, lets me write my nonsense, see that it was a bad idea, then throw it away without eating up more time than I needed to with satisfying all the type checking ceremonial stuff. Much nicer. It’s a linter that follows the “make it work, then make it right, then make it fast” iterative workflow that I’m used to.

Alas, I suppose if I wasn’t an imposter in the programming world, I would be able to dream up my changes and think them through in my head properly before committing them to my text editor. Maybe I wouldn’t even need to do that because my ideas are just great all the time instead of 50/50 between ok and terrible. I’m not smart like that, and it felt like go went out of its way to rub it in.

Maybe I used go wrong. I haven’t touched it in a decade. Is there a “hey ho your types are all out of sync but let’s try and compile anyway” option?

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

#163

Post by noitpmeder »

nine_zeros wrote: post #38

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.

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

#164

Post by ironman1478 »

This article has a really strange tone. For example, there is this section "There is an Any type and it renders everything useless". Yeah, so does C with (void*). Just because somebody is abusing a tool doesn't mean the tool is wrong. Any is valid with dealing with a dictionary type that is deserialized from some file. If somebody is just injecting Any into their code because they don't know what they are doing, educate them.

The takeaway that type hints are worse than doing nothing just doesn't comport with my experience where the type hinting has caught very legitimate subtle bugs one code that was infrequently used. I wonder if the author would make the same argument for TSAN, UBSAN, or ASAN? Coverity? Or other annotation systems that help outside of the compiler? These tools are godsends, but do have false positives if their scope is understood.

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

#165

Post by eyelidlessness »

ledauphin wrote: post #50
dtech wrote: post #41

Earlier quoted context omitted.

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

> However, even in Typescript it is nontrivial to _annotate_ these complex types

The only one which stands out to me as non-trivial in TypeScript is thrown exceptions… and even then only because you can only type them in a catch clause, and only with unknown, and they’re invisible to callers. But then this is why people who would care for checked exceptions quite reasonably just use something like a Result type.

But I agree with your conclusion completely, and it’s basically the same one I came to reading the post.

I was curious about how the current state of things compares to TS, as I may soon have a foray back into Python soon, and would be delighted to bring some static types into the mix. Pretty much as I expected, it’ll probably be more effort/less valuable than TS, but more valuable to me than to the author.

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

#166

Post by awinter-py »

possibly orthogonal, but fastapi's use of type hints to parse params + payloads for REST is life-changing

with the exception of some edgy form / upload issues, it's been bulletproof for me

fastapi feels like something the universe wanted to exist and type hints are a natural DSL for it

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

#167

Post by the_af »

TillE wrote: post #152
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…

Your criticism was: > it just doesn't work cleanly out of the box like in true statically typed languages So the response is entirely appropriate. Python is not a statically typed language, of course type hints don't make it behave exactly like a statically typed language.

Fair enough. I can see how my statement was not very clear.

I meant to say this: because Python's type hints don't work as well as true statically typed languages (based on my own experience), this makes them less useful and also makes them feel more like busywork. Because of this, my coworkers (who have no experience with statically typed languages either, and tend to dislike best practices and features unless they see a clear return of value from them) are hard to convince type hints are worth the time to learn and use them.

Also, let me restate we cannot pick the language. We can just make better or worse use of it.

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

#168

Post by rglullis »

the_af wrote: post #151
rglullis wrote: post #143

Earlier quoted context omitted.

Do your co-workers also only see the point of automated testing if you have 100% coverage? If you/your team want to use a statically typed language, then use one. Python is not it.

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 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. You can look at your past burn charts and say "look at this bug here, what caused and why did it take so long to fix? Is this the type of problem that would be easier to solve with static analysis of the code? Look at this refactor that we are planning for next quarter, should we try to increase the test coverage to make sure we have more confidence in the changes?"

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

#169

Post by sevensor »

The way to think about gradual type annotations is not like types in C. You're not saying "this variable is 8 bytes that we're going to interpret as a floating point number." What they do is let you express constraints on the behavior of your program, and then run another program to check whether those constraints have been violated.

Suppose you start with the function

    def foo(bar, baz):
        if bar > baz > 0:
            return bar / baz
        return "bar is not bigger"
And this is what you want the function to do, for some reason. But by the time you start writing other code, you've forgotten about the unusual "bar is not bigger" case, and you just assume you're always getting a number back. This could turn into a runtime exception somewhere else in your code because a field in some object somewhere now has a value of the wrong type, but you've never run into it so you don't know about the ticking time bomb.

Now you start adding type annotations to foo:

    def foo(bar: float, baz: float) -> float:
        ...
And when you check the types, mypy yells at you, and you realize you actually need to write this:

    def foo(bar: float, baz: float) -> Union[float, str]:
        ...
At this point mypy starts informing you about all the places you failed to handle the "bar is bigger" return value, and you go and fix them. You keep going until all of the constraints you've put on your code are consistent. You don't have to completely type everything for this to be useful, nor is it particularly important to check this stuff at runtime, because all mypy is doing is telling you that the code you've written satisfies the assumptions you're telling it about.

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

#170

Post by nas »

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…

I've found that it's pretty easy to slowly enable mypy checking. You can mark modules with "type:ignore" to make mypy ignore them. Then, you can move to marking individual statements with "type:ignore". Finally, you can start marking modules with "mypy: disallow-any-generics" at the top. That requires that functions are annotated with types.

In a large code base, our team has found type annotations and mypy to be quite helpful. If you are writing a quick-and-dirty script, forget about wasting time with type annotations. However, for long-lived and important code, it seems to be worth adding the types.

Another thing I noticed, if your type annotations are hard to write, e.g. lots "Union", "Optional" or deeply nested type expressions, it's probably a sign that your code is poorly designed. Think about what types you actually want to consume and return. Define new containers using dataclasses or attrs to keep the types simple, if required.

Post reply on HN