Live data from Hacker News

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

uninformativ.de

251–260 of 597 posts

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

#251

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.

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

#252

Earlier quoted context omitted.

Like the author said, the weird thing is that it goes both ways. I'm pretty sure if you try to return `any` from a function with an explicit return type in TypeScript you'll get pinged for it.

Not with any TSC settings I've ever used.

noImplicitAny is a very common config option that helps catch a ton of bugs. I wouldn’t use TS without it.

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

#253

Earlier quoted context omitted.

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

Your suggestion to “use a recursive union type” and that being “ugly … if your type checker doesn’t … support recursive types” being required to support varying JSON is my point: Python types don’t support a common Pythonism used frequently in my work. In fact, you admit that even fixed JSON can be difficult without a 3rd party library. You’re lecturing me like I don’t understand types without realizing that you repe…

I think I might not have been clear: this is not a limitation of the type system, but of a specific type checker (mypy), that will hopefully be fixed soon. Both Pyright and Pyre support recursive type aliases right now. Open one of their playgrounds and you'll see that the following, intuitive definition

  JSON = Union[
      None,
      bool, 
      int,
      float,
      str,
      List['JSON'],
      Dict[str, 'JSON'],
  ]
works without issue.

>In fact, you admit that even fixed JSON can be difficult without a 3rd party library.

Sure, but that's just because the standard library (for now?) doesn't offer deserialization with runtime validation. Java doesn't have that either, if you want to parse JSON you'll have to either roll your own or rely on a third party library.

Don't get me wrong, the situation isn't perfect, but especially if you use the 'right' tooling, you can in my experience already get a perfectly serviceable experience, which to me is indicative that the type system itself is fine and pythonic, it's just the tooling that is lagging a bit behind at the moment.

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

#254

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

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

#255

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…

The fact that we can't have a type for JSON really does make it look like a toy.

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

#256
post #254

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

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.

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

#257
post #132

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…

This is exactly my experience. I've also found that Python's type annotations for even basic stuff like are way clunkier to write. For example an optional requires a typing.Optional import or a an ugly "| None" instead of a question mark like TS has. And good luck trying to annotate some complex / nested json, you'll need a bazillion intermediary classes.

There's a subtle difference between TS' question mark and union. The question mark means "this argument is optional", which can be different than "this argument can be undefined".

The following code is valid:

  function foo1(value?: number) {}
  
  foo1()
But the following code will raise a type error:

  function foo2(value: number | undefined) {}
  
  foo2()
In practice, that rarely becomes problematic. But it's good to know the difference

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

#258
Look there's a lot of good, long winded comments here. If anyone is like me and scrolls for an easily digestible one: here's the TLDR.

Eventually you'll get fed up with not knowing what type each argument to an API call needs to be. You'll either get on board with python type hints, or you'll graduate to a typed compiled language, or you'll languish in the trough of python productivity.

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

#259
post #256
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#.

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 maybe Kay had C and Pascal in mind, when he thought of objects as being the basis for a proper dynamic type system.

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

#260
post #255

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…

The fact that we can't have a type for JSON really does make it look like a toy.

This is (for now) a limitation of mypy, not of the type system. Pyright and Pyre both can type JSON since they support recursive type aliases.
Post reply on HN