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

181–190 of 597 posts

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

#181

Post by kirbyfan64sos »

phailhaus wrote: post #67

Python's type system is a disappointment, but I don't think this article does a great job of explaining why. My biggest gripes: 1. There is no way to get typing like dataclasses without writing your own mypy plugin. The syntax is simply not expressive enough to do it. This means that if you want to be productive with a library like Pydantic, you also have to add the mypy plugin to your dependencies and add it to your…

> There is no way to get typing like dataclasses without writing your own mypy plugin. The syntax is simply not expressive enough to do it. This means that if you want to be productive with a library like Pydantic, you also have to add the mypy plugin to your dependencies and add it to your mypy config. Otherwise, no typing.

This would be solved by PEP 681, which originates from (and is already used in) pyright: https://peps.python.org/pep-0681/

> 3. To this day, there is still no way to express optional keys. Not "Optional" keys, but keys that can be left out of your dictionary. The closest you can get is this weird hack where you can set `total=False` in your TypedDict, which makes all keys optional.

This is solved by PEP 655, which introduces NotRequired: https://peps.python.org/pep-0655/

It's implemented in mypy 0.930: https://mypy-lang.blogspot.com/2021/12/mypy-0930-released.ht...

> I really wish Python learned from Typescript, but it's too late at this point

Personally, I feel like it's partly just entirely different styles: Python relies on a mix of nominal and duck types, whereas JavaScript is much more focused on structural typing. As a result, there are a lot of things like TypedDict that are absolutely essential for JS to even function but a decent bit less so in idiomatic Python code (keeping a significant amount of dicts around uses much more memory than objects, I recall a PyCon talk explicitly mentioning this too).

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

#182

Post by Diggsey »

nas wrote: post #170
Diggsey wrote: post #161

Earlier quoted context omitted.

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

Right - I mean we had mypy passing across the whole project, but it just wasn't detecting any issues because so many of our types had to be ignored because mypy didn't understand that the runtime type of a Column field in SQLAlchemy is not Column, and things like that.

Rather than maintain all of the mypy stubs for no benefit, we decided to just scrap mypy.

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

#183

Post by totony »

linsomniac wrote: post #180

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…

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

I agree this is useful, but to me the most useful feature of types are the self-documentation. It's crazy the difference between a non-typed library with shitty documentation vs a typed library with shitty documentation.

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

#184

Post by edgyquant »

hermitdev wrote: post #88
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…

Personally, I took exception to the following from TFA: > Python is a dynamically typed language. By definition, you don’t know the real types of variables at runtime. This is a feature. In "you don’t know the real types of variables at runtime", this is just flat wrong. One doesn't know the real type of a variable until runtime. It seems to me the author maybe has a bit of confusion between weak typing and dynamic t…

I get what they mean though. In a typed language you know the type of a variable at compile time. In dynamically typed languages there is nothing to enforce this and a variable can be passed with any type. So there wording may be off but the point stands.

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

#185

Post by edgyquant »

dtech wrote: post #41
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…

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.

The ability to slowly add typed code to an existing database has been a lifesaver. I always hated JS because of callback hell (and the notions around its community) but since I started working with typescript my mind has been changed. I love it

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

#186

Post by np_tedious »

linsomniac wrote: post #180

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…

> I'm not even using mypy often, if ever.

Hopefully your CI does?

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

#187

Post by majormajor »

> But as a general rule: You don’t know if there really is a tool in place to check them. You especially don’t know this when you join a new project, but it’s also a little hard to tell afterwards. Did the mypy task in your build pipeline silently break? Maybe mypy is misconfigured? Maybe it spits out errors but does not cause build jobs to actually fail? What if mypy has a bug? What if mypy is not even complete and doesn’t cover all cases?

This seems like an extreme overstatement and a sign of a very weird team environment.

Are you not running your linting and validation locally?

Heck, when dealing with some poorly-typed external code, I run mypy manually to help me figure out what the stupid types I need to assign even are. This is far from ideal, but in lieu of a better solution, it works for me.

I just find the idea that people would be adopting typed Python and then completely ignoring the type-related tooling a bit wild.

And sure, libraries can have bugs, you can open yourself up to big holes with Any... and in cases where I'm super worried about things like that, I'm generally not using Python. But I'd rather use Python with type hints + use the tooling in a sane way then not use the type hints at all.

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

#188

Post by Bedon292 »

the_af wrote: post #127
ledauphin wrote: post #121

Earlier quoted context omitted.

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

Not my experience!

What speed are you looking for in your CI pipline that you are not getting from mypy? Perhaps you are working on a much larger codebase than I am but the app I use it in takes under a minute. And all the unit tests take longer to run.

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

#189

Post by whimsicalism »

nas wrote: post #170
Diggsey wrote: post #161

Earlier quoted context omitted.

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

I disagree with your last line, especially for Optional (Union in python is basically useless IMO).

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

#190

Post by linsomniac »

Hot take: If you think for a moment about the feature name, "type hints", many (all) of the objections the author has become clear.

It is not called "static typing". It's called "type hinting". Based largely on the name, I wouldn't expect it to error at runtime if you tell me 'hello' is an int. That's just a type hint. I WOULD expect a static analysis to flag is, and mypy indeed does.

Post reply on HN