4 ms·

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 h

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 advent of Typing has changed my opinion on these two very similar languages? - JavaScript without types is a mess, whereas Python comparatively was much better, esp since it does runtime duck type checks. - Python type hints are much similar to Flow type hints in JS, which I tried, but ditched for the same reasons as Python type hints. - I was hesitant to try TS's all in approach, cause it was harder to introduce into a project, but after having converted a number of projects to TS, I can see that going all-in is a much better approach than just adding hints as you go. - TS does checks at many more levels. Eg, if a property is optional or could have different types, it is a syntax error if I don't check the value is valid before use. - TS does an amazing job of auto-detecting types, so most of the time you don't need to specify types, and it enforces these just as if you declared them. - TS has reached the critical mass were most popular packages now include type definitions, I very rarely have to add @types/* anymore. This means you get full intelisense on all 3rd packages! I spend a lot less time referring to documentation now! In hindsight, compiling out types is a great work flow. TypeScript is so good that it has made me enjoy Python less. If there was ever a Python equivalent to TS which reached a critical mass of support, I'd jump all-in in a heartbeat.

hannofcart 4y ago
To be fair, you're comparing a static typed language that transpiles to JS with a type annotation system for a dynamic lang. Pylint is closer to Flow than Typescript.
- Humphrey 4y ago
  Oh of cause -- and I suspect TS only became so good because it had the freedom to be a new language.
Frotag 4y ago
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.
- goodoldneon 4y ago
  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
  - Loeffelmann 4y ago
    I really think the second one shouldn't raise a type error. This is already invalid: function foo1(arg1?: number, arg2: number) {} In that case you have to use function foo1(arg1: number | undefined, arg2: number) {} foo1(undefined,1); But other than that what is the use case?
    - goodoldneon 4y ago
      The second one raises an error: https://www.typescriptlang.org/play?#code/AQMwrgdgxgLglgewqBCBMAKAbgQwDZgCmAXMBGALYBGhATsAD7CQAmhIcEhLAlMAN4BfAFDBgwkKkw8gA https://www.typescriptlang.org/play?#code/AQMwrgdgxgLglgewqB... This conflation of "optional" and "undefined-able" is more obvious in interfaces. This is why TypeScript added the `exactOptionalPropertyTypes` option: https://www.typescriptlang.org/tsconfig#exactOptionalPropertyTypes https://www.typescriptlang.org/tsconfig#exactOptionalPropert... Sometimes "is not defined" needs to be treated differently than "is set to undefined"
remram 4y ago
The fact that we can't have a type for JSON really does make it look like a toy.
- ImprobableTruth 4y ago
  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.
- ok123456 4y ago
  Use pydantic then. Then you get type checking and validation for your json blobs.
bayesian_horse 4y ago
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.
fulafel 4y ago
The realities of the browser platform have indeed created a unique environment where many nice languages have appeared that compile to JS. Besides TypeScript there's Elm, ReasonML, ClojureScript, and many more. There are a some competing languages for the Python runtime as well: https://github.com/vindarel/languages-that-compile-to-python https://github.com/vindarel/languages-that-compile-to-python
TomBombadildoze 4y ago
There are many complaints in this discussion about inaccuracies in the post but you've actually captured the essence of the problem--type hints just don't solve the problem well. My team began using type hints and aggressively applied mypy to new code starting a couple years ago and it _has_ helped immensely. However, we also started doing some work in Typescript around the same time and the difference in developer experience and code quality is pretty clear. Typescript is just a better solution to the problem of adding type information to a dynamic language. What's especially frustrating is living through the design and early life of asyncio (Guido, you should have adopted the gevent model), then getting excited about typing, only to find it is also not very good. What's _especially_ frustrating is that Typescript existed two years before PEP 484 was published, so the core developers had ample time to seek inspiration elsewhere, and they came up with a sub-standard solution. Python needs a Typescript analogue, with a compiler that targets vanilla Python.

hannofcart 4y ago

To be fair, you're comparing a static typed language that transpiles to JS with a type annotation system for a dynamic lang. Pylint is closer to Flow than Typescript.

Humphrey 4y ago
Oh of cause -- and I suspect TS only became so good because it had the freedom to be a new language.

Frotag 4y ago

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.

goodoldneon 4y ago
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
- Loeffelmann 4y ago
  I really think the second one shouldn't raise a type error. This is already invalid: function foo1(arg1?: number, arg2: number) {} In that case you have to use function foo1(arg1: number | undefined, arg2: number) {} foo1(undefined,1); But other than that what is the use case?
  - goodoldneon 4y ago
    The second one raises an error: https://www.typescriptlang.org/play?#code/AQMwrgdgxgLglgewqBCBMAKAbgQwDZgCmAXMBGALYBGhATsAD7CQAmhIcEhLAlMAN4BfAFDBgwkKkw8gA https://www.typescriptlang.org/play?#code/AQMwrgdgxgLglgewqB... This conflation of "optional" and "undefined-able" is more obvious in interfaces. This is why TypeScript added the `exactOptionalPropertyTypes` option: https://www.typescriptlang.org/tsconfig#exactOptionalPropertyTypes https://www.typescriptlang.org/tsconfig#exactOptionalPropert... Sometimes "is not defined" needs to be treated differently than "is set to undefined"

remram 4y ago

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

ImprobableTruth 4y ago
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.
ok123456 4y ago
Use pydantic then. Then you get type checking and validation for your json blobs.

bayesian_horse 4y ago

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.

fulafel 4y ago

The realities of the browser platform have indeed created a unique environment where many nice languages have appeared that compile to JS. Besides TypeScript there's Elm, ReasonML, ClojureScript, and many more. There are a some competing languages for the Python runtime as well: https://github.com/vindarel/languages-that-compile-to-python https://github.com/vindarel/languages-that-compile-to-python

TomBombadildoze 4y ago

There are many complaints in this discussion about inaccuracies in the post but you've actually captured the essence of the problem--type hints just don't solve the problem well. My team began using type hints and aggressively applied mypy to new code starting a couple years ago and it _has_ helped immensely. However, we also started doing some work in Typescript around the same time and the difference in developer experience and code quality is pretty clear. Typescript is just a better solution to the problem of adding type information to a dynamic language. What's especially frustrating is living through the design and early life of asyncio (Guido, you should have adopted the gevent model), then getting excited about typing, only to find it is also not very good. What's _especially_ frustrating is that Typescript existed two years before PEP 484 was published, so the core developers had ample time to seek inspiration elsewhere, and they came up with a sub-standard solution. Python needs a Typescript analogue, with a compiler that targets vanilla Python.