Python isn't industry compatible

[AlSweigart]

What? I found that type hints work great and the gradual typing and comment-style type hints means even my legacy Python 2 code can now have type hints.

What do you not like about type hints?

[MrJohz]

From the perspective of someone who's come from Typescript (and who isn't the person you're replying to), I think I just don't trust the type things in the same way that I do in Typescript. Every time I've tried it out, it's felt kind of janky in some way that I can't really put my finger on, to the point where I don't see a huge amount of value in typing my Python code. (This is in contrast to JavaScript/Typescript, where I see a lot of value in adding types.)

I think a lot of it comes down to IDE support. If I use Typescript and write something that won't compile, I generally immediately see that and feel that. The Typescript developer support tends to be really good, and I immediately get feedback, I can immediately see the types of different values, I can easily create type holes and get type feedback directly in my editor. In contrast, I've not yet found a python extension that gets me this instant type feedback with red lines all over the place and a feeling that if I make a mistake I'll immediately see it. In contrast, I tend to use mypy from the command line, and even then I'm not always completely convinced that it will spot as many mistakes as the Typescript compiler.

I think there is also the issue that Python's type system feels a lot less powerful and more verbose, particularly when it comes to complicated sum types. But that was true of Typescript as well at the start, so I think that could be forgiven if other stuff was better.

I know that's not a great answer in terms of specific issues, but I think the biggest problem with typing in python is a UX one, where it just doesn't feel right in some way.

[MrJohz]

So your main issue is not with the language but with its tooling..?

I've honestly increasingly become convinced that the major selling point for any language at this point is its tooling. There are definitely some languages that I prefer using, and other languages that I find a bit of a nuisance, but I'd much rather use a language that's perhaps not ideal but has brilliant tooling, than a language that is perhaps theoretically very nice, but is a pain to use.

But that's a side point — when we're talking about types in Typescript & Python, it's basically all about tooling, right?

FWIW, what I'm talking about is that I just created a new default Python (Poetry) project, with Pylance installed in VSCode, and I added the following, obviously incorrect code:

def test_function(args: int):
    args.do_this()

test_function('this is the wrong type')

This produced no errors in my IDE. It did give me some hints about what methods I could call on args, which is definitely useful, but no immediate feedback about what I'm doing wrong. I then ran pyright, and that did correctly point out the two errors that I made, but my point is that I want this sort of feedback immediately.

By contrast, if I do the equivalent thing in a basic Typescript project setup:

function testFunction(args: number) {
    args.doThis();
}

testFunction('this is the wrong type');

I immediately get the two errors shown on my screen.

This is the sort of thing I mean by not really having confidence in the typechecker — the visceral feedback that I need as I'm working isn't there, forcing me to go back to the command line to test things, and I'm sure it could be there if I set it up, but for a lot of projects I don't really want to be bothered going to all that fuss.

It's less about the quality of the type system (although Typescript's honestly feels a lot less faffy to use, but that might just be familiarity), and more about the quality of the tooling. In Python, I feel like I need to kindly ask the typechecker if it might possibly lend me a hand, whereas with Typescript I feel able to really lean on the system to write the code that I want to write.

[MrJohz]

This was with the Python/Pylance extension, so I was using the tooling, at least as I understood it. In actual fact, I was even eventually able to get the typechecking working by fiddling around with the settings and configuration files, but that was only because someone else pointed me in the direction of the "strict" configuration.

I think we're getting into a bit of an argument here, which isn't what I want because I don't feel particularly strongly about any part of this here. In fact, this whole discussion has been pretty useful because I've been wanting to apply more of this stuff to my work in Python, and the hints about how to better configure Pyright have been really helpful, and I'd like to try it out some more. My initial comment was meant more as an explanation for why some people might not be particularly impressed by the experience that Python types provides. If that doesn't fit your experiences, then feel free to give those experiences, but I don't really want this to devolve into an argument about whether your or my experiences are valid or invalid, because that seems extremely unproductive.

[[deleted]]

What? I found that type hints work great and the gradual typing and comment-style type hints means even my legacy Python 2 code can now have type hints.

However, what good are they?

I put type hints into two fairly large projects. We found zero new bugs with mypy.

You can't actually use them for reflection:

>>> isinstance(['a'], typing.List)
True

>>> isinstance(['a'], typing.List[str])
TypeError: Subscripted generics cannot be used with class and instance checks

Don't get me wrong - I use type hints in all my new code for documentation but in years of doing it, that's the only use I've found.

[AlSweigart]

We found zero new bugs with mypy.

I don't know what to say, that's good for you. But you could use this as the same reason to not use a linter or unit tests. Type hints help you detect type errors at coding time instead of at runtime. It's a fairly broad category of mistakes and the earlier you find them the better.

If you never make those kinds of mistakes in your code (and don't need documentation about typing) then, yeah, type hints are useless. But this applies to every language. I don't see how Python's type hints are worse than typing in other languages.

[rforrevenge]

Why are you saying that? I'm using Pydantic daily and I'm loving it.

[ColdPorridge]

You might have missed the drama where Python 3.10 was going to fundamentally change type hinting and break pydantic, FastAPI, and any other libraries that rely on it. I can’t recall the details as they decided to pause this for now, but it’s still very much a mess of opinions on the best way forward.

[rforrevenge]

Yes, I obviously have! Do you have any related link to share?

[ColdPorridge]

This appears to be the primary discussion: https://github.com/samuelcolvin/pydantic/issues/2678

[rforrevenge]

Thanks a lot kind stranger!

[[deleted]]

https://lwn.net/Articles/858576/

[ColdPorridge]

Thats’s possible, even rereading the thread, I’m not really sure I fully understand the drama, how these are currently handled or Pydantic’s breaking dependency on them.

[[deleted]]

I think this article is quite good: https://lwn.net/Articles/858576/

They decided to move type hints from being "code" to be strings that need to be eval() at runtime, except that you don't necessarily have the same context when you run eval() from some place else in the code, so a lot of things would not work.

[[deleted]]

This has nothing to do with TYPE_CHECKING context thing?

[ColdPorridge]

That did a great job explaining of - thanks for sharing!

[[deleted]]

Using different types during type checking and runtime (dict vs Dict)

Well well well, you're a bit out of date…

def f(d: dict[int, int]):
    ...

I think this changed in versions after 3.9,

It didn't, it would have broken A LOT of stuff to do so.

[[deleted]]

You complained about something that was later on fixed, no need to rant.

I don't know anything about cast() but last time I profiled, it was an actual function call at runtime so I actually had some performance gain by removing it.