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

291–300 of 597 posts

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

#291

Post by vegai_ »

tootie wrote: post #254
jsmeaton wrote: post #239

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…

I'm baffled by people loving type hints in python when strongly typed languages have been widely available for so long. This is why people liked java and c#.

There's a difference between putting on your own seatbelt and the car forcefully tying you into the chair every time you sit.

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

#292

Post by phailhaus »

RhysU wrote: post #251
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…

If you have a dictionary with heterogenous, optional keys then I believe you have a struct-like class. If you have any constraints on the keys beyond a homogeneous domain and a homogeneous range then you have a struct-like class.

Avoiding classes has a couple of benefits:

1. It reduces the overhead to use your interface. Your users don't have to import your struct classes, and can just pass in bare dictionaries. If Python's typing was more effective, these dictionaries would also be type checked to make sure you're calling the library's APIs correctly.

2. It deliberately closes off the option of adding state or initialization logic. Classes let you do way more than just encode a struct, and as a codebase grows they have a tendency to become more complex just because they can (like a gas filling its container). This makes APIs harder to maintain and work with. Sometimes, all you need is "raw structs".

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

#293

Post by bayesian_horse »

goatlover wrote: post #259
minism wrote: post #256

Earlier quoted context omitted.

Same thing happened to the JS world with typescript (though typescript seems more powerful than python type annotations). Its fine though - I'm glad the culture is trending towards understanding that strong typing saves you time rather than causes you extra time. This is true even for very small and simple programs, and even if you're the only developer.

The typing debate has been ongoing for decades, and it's switched back and forth a few times. JS, Python and Ruby all came out in the 90s, after there were plenty of statically typed languages being used at the time. Alan Kay has argued that types are too restrictive and usually don't describe the kind of data the program is really about. Maybe that's not as true for an advanced typing language like Haskell. And mayb…

C,Pascal, even C# and C++ need type annotations mostly to actually make the program work. The type systems in Typescript and F# are more about helping the developer than helping the compiler.

Python type hints are slightly different because there are type hints as a syntax feature and then there is type checking, which can be static like mypy or during runtime like Beartype. Every type checker comes with its own type system, though they are hopefully somewhat similar...

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

#295

Post by bayesian_horse »

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…

The "print" function will take any Python object and call its "__str__" method. Not sure if it will do it to a string, but the outcome would be the same.

As far as I remember, the "__str__" method is present on all objects in some form, so print will happily take any type.

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

#296

Post by Too »

neves wrote: post #269
jsmeaton wrote: post #239

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?

Mypy can be configured to ignore modules based on their names.

Though honestly I think it’s worth it to just bite the bullet and spend a full day or two to go through and fix every single error. After this you will have a much easier time navigating code base. I mean, your “new code” is probably modifications to your old code or calling your old code right? So you want to have at least the boundary between new and old typed. It’s quite satisfying anyway, as you will likely learn and discover tons of bugs on the way.

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

#297

Post by bayesian_horse »

Humphrey wrote: post #118

While I love the idea behind Python's type hints, they are merely a shadow of the success of TypeScript. Like the author, I've mostly given up on adding type hints in my Python code. I now only use them when I want to help my IDE find autocomplete suggestions. Whereas TypeScript was a game changer for JavaScript. I used to hate JavaScript, but somehow TypeScript has become one of my favourite languages! How has the a…

In my opinion type checking in Python is a lot less necessary, which throws off the cost/benefit calculation. And the cost/benefit ratio also varies with the size of the codebase, team and other things.

Let's emphasis the "gradual" part. The more libraries are carrying type annotations, the more helpful IDEs will be and the easier it is to type-check your own code.

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

#298

Post by cocoa19 »

coder543 wrote: post #263
tootie wrote: post #254

Earlier quoted context omitted.

I'm baffled by people loving type hints in python when strongly typed languages have been widely available for so long. This is why people liked java and c#.

There are way more differences between Python and Java than just "having explicit types". If that was the only difference, your comment would make more sense. I would even go so far as to say that Java's type system is the very one that left such a bad taste in people's mouth that many people swore off explicitly typed languages for a decade or two. It really was that bad, especially before the last few years. It add…

And many of us prefer simplicity in languages.

When a language like typescript supports too many obscure features, or multiple ways to do the same thing, the curve becomes too steep to be proficient.

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

#299

Post by bayesian_horse »

goodoldneon wrote: post #267
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…

Agreed. Also, Mypy's dict inference is too broad, making TypedDict a little less useful. For example, the following code raises a Mypy error even though `foo` conforms to `Foo`: import typing class Foo(typing.TypedDict): a: int def do_thing(value: Foo) -> None: return foo = {"a": 1} # error: Argument 1 to "do_thing" has incompatible type "Dict[str, int]"; expected "Foo" do_thing(foo) But TypeScript can figure it out:…

This is a misunderstanding of the Python type system. In the Typescript example you are depending on "foo" being structurally compatible to the "Foo" interface.

In the Python case, "foo" and "Foo" might look structurally compatible, but they aren't. "Foo" isn't just a type, it's an object of type "class". You can for example print(Foo), you can't console.log(Foo). "foo" is not an instance of the Foo class. What you are looking for is "dict[str, object]".

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

#300

Post by smohare »

bayesian_horse wrote: post #289
mountainriver wrote: post #233

Earlier quoted context omitted.

Not typing is kinda a crazy way to write programs when you think about it. It can be beneficial in certain niche use cases like data science where code is always terrible. For everything else, types are a huge boon for the developer and everyone consuming their work

Have you tried it? Python has gained most of its popularity before type hints, and I would (wildly) guess 99% of Python programmers don't even use type checking at all. Static typing is completely viable and I hear those arguments mostly from those who didn't use Python for a long time. The added productivity makes up for a little more debugging while the program is running. I'd also posit that many Python codebases…

If you mean “Python programmers” to be random sysadmins that write hack code residing on a random EC2 instance then maybe you’re right. But most I get the sense you haven’t looked at many Python libs lately.

The added productivity of non-typed Python is such a ridiculous myth to anyone who has to maintain significant Python code bases. Sure, it makes you more productive for one-off exercises but the moment you’re having someone else inspect your code the productivity gains vanish. This largely true of dynamic languages more generally except in niche caches (e.g., ORMs) where types are strongly implicit.

I say all this as a mathematician that is used to reading papers full of symbols packed with implicit information. The code I’ve read from gung-ho dynamic typing advocates is some of the most painful drivel I’ve ever had to wade through.

Post reply on HN