15 ms·

Python not only has types but it's type system is superior to typeScript. Get this python has sum types and exhaustive pattern matching exactly like rust or ha

Python not only has types but it's type system is superior to typeScript. Get this python has sum types and exhaustive pattern matching exactly like rust or haskell. The only problem with python are the libraries are sometimes written with tricks that make static typing ineffective. Other than that it is really really good at scale. Better API then typescript imo which is really it's main competitor. edit: (rate limiter is preventing from replying to everyone... I will respond to everyone.)

seabrookmx 3y ago
Yes but the if you want to do ahead-of-time type checking you need to run a tool like mypy, and none of those tools are as comprehensive or performant as Typescript. Also the ecosystem of libraries with type annotations is much smaller (Typescript has the first mover advantage, after all).
- corethree 3y ago
  I literally said it supports exhaustive pattern matching which adds a level of safety and flexibility superior to that of type script. Many IDEs have real time type checking that highlights the errors so don't even have to run the external checker. Even if you don't use IDEs running the type checker is measured in seconds. Not far off from linters that most people will also use for TS. What you say about the libraries is true though. But you can always place a type "shell" around those libraries such that your code is type safe. The other main problem with the libraries in python is that a lot of people who use python are data scientists who haven't figured out why types are so great. Those guys are the main ones holding the libraries back.
  - chlorion 3y ago
    >I literally said it supports exhaustive pattern matching which adds a level of safety and flexibility superior to that of type script. I don't have an opinion on which language is superior here, I've never written typescript or even javascript before, but I think saying that python's type system/checkers is superior because of this one feature is not correct. I'm also skeptical of the claim that typescript doesn't support exhaustive branching. This very well could be true but it seems hard to believe. I'm a big fan of exhaustive branching, but I think there are other things that are as or more important.
    - corethree 3y ago
      >I don't have an opinion on which language is superior here, I've never written typescript or even javascript before, but I think saying that python's type system/checkers is superior because of this one feature is not correct. I meant, it supports basically every common/useful type feature in addition to this one which is very powerful. >I'm also skeptical of the claim that typescript doesn't support exhaustive branching. This very well could be true but it seems hard to believe. It is true. Look it up. Very few languages support this feature. Python is able to do it because the type checker is external so developers can create all kinds of features and move faster then core python development. But by default other then Rust, Rust is basically the only popular language that officially has this concept.
  - seabrookmx 3y ago
    Maybe comprehensive is the wrong word to use. But Typescript is definitely more mature. I really like to run these checks alongside black, pyupgrade etc. in my CI pipelines. And under the hood your IDE is just running the same "external" checker and parsing it's results to provide it's smarts. As for performance, early mypy versions took literally minutes on a moderately sized FastAPI codebase I maintain. The team (which includes Guido himself!) literally created a new python native compiler (mypyc) to try and improve performance of the tool. I like types in Python but it's early days compared to a more mature tool like Typescript. IMO it's pretty clear cut if you've spent significant time using both.
insanitybit 3y ago
You can't even represent `Json` in Python's type system because it would require a recursive type. edit: I think this is actually a Python type annotation limitation but it's possible that's mypy, although I think in 99% of cases those are fine to conflate (I have used other Python type systems).
- dazzlefruit 3y ago
  In VSCode (which uses PyRight/PyLance) and Python 3.10: JSONObject = None | str | int | bool | list["JSONObject"] | dict[str, "JSONObject"] # this type checks a: JSONObject = {"a": [1, 2, "7", True, {"false": None}]} # this doesn't type check b: JSONObject = {"a": [1, 2, "7", True, {"false": object()}]}
  - insanitybit 3y ago
    Cool, guess they finally fixed this. Must've been in the last ~1 year, give or take. Of course, it relies on quoting your types, which is... a matter of taste, I suppose.
    - dazzlefruit 3y ago
      Quoting types that are defined later is a wart but it's not very bad. VSCode's UI will happily handle it as if the quotes weren't there.
    - npage97 3y ago
      You can also use from __future__ import annotations so the quotes become unnecessary. https://peps.python.org/pep-0563/ https://peps.python.org/pep-0563/
      - insanitybit 3y ago
        Does that work with recursive types? I have had mixed results with `from __future__ import annotations` personally, but I haven't written much Python in ~a year or so.
crabbone 3y ago
Surprise: all languages have types. Superior to TypeScript is neither a high bar, nor is this any kind of objective metric. I don't know why sum types are a blessing, also I don't know why pattern matching makes anything better. I can name a lot of problems with Python, and I'm sure that libraries isn't the only one. For example, for no reason, Python has multiple unrelated mechanisms to manage program state (object, clojures, context managers). Or, here's another one: it has multiple public API for dealing with filesystem (i.e. os.path and pathlib), both of which are all sorts of bad, but just the fact that it has two, where one would do is bad. It's not possible to make static typing ineffective. Static typing is a given, it happens in the virtue of you having a program. You may argue that it doesn't exist if unobserved in the same way how a tree that falls in the forest doesn't really fall if unnoticed. But, really, it's there, and it's there in every language. You cannot make it ineffective. It's like making centimeters ineffective -- I would struggle to imagine what that may possibly mean.
- dazzlefruit 3y ago
  Why is pathlib bad? Edit: I'm asking because pathlib is as good as a Python lib could be for me. Path manipulations are extremely clear and always safe. What more do you need?
  - Izkata 3y ago
    I'm guessing verbosity? It also reads like they don't know why pathlib exists and assume they were created at the same time. os.path came first, often works by poking the filesystem directly even when it doesn't seem like it needs to (vague memory, not completely certain), and I believe has os-specific quirks (so code won't necessarily work without changes). pathlib was created later as a pure-python implementation that allows for manipulation paths without touching the filsystem except when you explicitly tell it to. Because it's also pure python I don't think it has any os-specific quirks either, but I haven't explored it in depth. Code should work across operating systems without changes. I think I also remember at one point people talking about completely replacing os.path with pathlib, or at least gutting os.path to the essentials that wouldn't work as part of pathlib.
  - 3y ago
Timon3 3y ago
> Python not only has types but it's type system is superior to typeScript. I strongly disagree. It might be better at some things, but it's much worse at others. Many functions can't be accurately typed (try, for example, to make a well-typed function that concatenates two arbitrary fixed-size tuples), and as far as I know generic type transformations can't be implemented (random example "this type takes a Dict[str, Any] and returns an object with each key turned into a function").
- dazzlefruit 3y ago
  For the tuple example: from typing import TypeVar T, U, V, W = TypeVar('T'), TypeVar('U'), TypeVar('V'), TypeVar('W') def concatenate(a: tuple[T, U], b: tuple[V, W]) -> tuple[T, U, V, W]: return a + b For the generic type transformation example, I'm not sure what you mean: from typing import Any, Callable Transformer = Callable[[dict[str, Any]], dict[Callable, Any]] This seems to match your question but it's really weird.
  - Timon3 3y ago
    Your tuple example only works if both tuples have two elements. I specifically mentioned arbitrary fixed-size tuples (as in, tuples with an arbitrary non-variable length). Your generic type transformation example also doesn't come close to what Typescript does. The resulting dict will not have known keys based on the keys of the input dict. In Typescript I can write a function that takes an object with known keys, and it returns an object with those same keys having their values mapped to a different type, with the keys still known. I threw together a quick example - just look at the type of resultA/resultB by hovering over the variables[0]. But both are great examples - they are probably the closest you can get in Python, and they are so far removed from the thing I want to represent that they are completely useless. [0]: https://www.typescriptlang.org/play?#code/MYewdgzgLgBAhjAvDA3gKBjAZiEAuGKAJwFcBTAGgxgCM4iCs4AbCS6ugLwLBOeaoBfNGlCRYNJKmo58MACwAmKpjoMYAIgAWZfiBgB3EEWYATDStpxuMANoBdISKwkwwKAEtwhInEg4iAFsAeRoAKzJ3AB4AFRgyAA8oMjBTCBgAJUjjUyjoIg8wAHMKeDAATwA+SoAKEHCCGIBKAhQ7AGkYQpgAazJykCwYGPsCGqakSuHbdvsYQWlMIjIoEiIwGAB6TcIQUxA0YVFwaBhliD4oAEEpYj8IAJDwyKgauCbj8TOyC+YoACFbr5-MYnhF3DUaE0gA https://www.typescriptlang.org/play?#code/MYewdgzgLgBAhjAvDA...
timeon 3y ago
> sum types Even PHP have those now. TypeScript is lagging here. Hopefully, they will include it too one day.

seabrookmx 3y ago

Yes but the if you want to do ahead-of-time type checking you need to run a tool like mypy, and none of those tools are as comprehensive or performant as Typescript. Also the ecosystem of libraries with type annotations is much smaller (Typescript has the first mover advantage, after all).

corethree 3y ago
I literally said it supports exhaustive pattern matching which adds a level of safety and flexibility superior to that of type script. Many IDEs have real time type checking that highlights the errors so don't even have to run the external checker. Even if you don't use IDEs running the type checker is measured in seconds. Not far off from linters that most people will also use for TS. What you say about the libraries is true though. But you can always place a type "shell" around those libraries such that your code is type safe. The other main problem with the libraries in python is that a lot of people who use python are data scientists who haven't figured out why types are so great. Those guys are the main ones holding the libraries back.
- chlorion 3y ago
  >I literally said it supports exhaustive pattern matching which adds a level of safety and flexibility superior to that of type script. I don't have an opinion on which language is superior here, I've never written typescript or even javascript before, but I think saying that python's type system/checkers is superior because of this one feature is not correct. I'm also skeptical of the claim that typescript doesn't support exhaustive branching. This very well could be true but it seems hard to believe. I'm a big fan of exhaustive branching, but I think there are other things that are as or more important.
  - corethree 3y ago
    >I don't have an opinion on which language is superior here, I've never written typescript or even javascript before, but I think saying that python's type system/checkers is superior because of this one feature is not correct. I meant, it supports basically every common/useful type feature in addition to this one which is very powerful. >I'm also skeptical of the claim that typescript doesn't support exhaustive branching. This very well could be true but it seems hard to believe. It is true. Look it up. Very few languages support this feature. Python is able to do it because the type checker is external so developers can create all kinds of features and move faster then core python development. But by default other then Rust, Rust is basically the only popular language that officially has this concept.
- seabrookmx 3y ago
  Maybe comprehensive is the wrong word to use. But Typescript is definitely more mature. I really like to run these checks alongside black, pyupgrade etc. in my CI pipelines. And under the hood your IDE is just running the same "external" checker and parsing it's results to provide it's smarts. As for performance, early mypy versions took literally minutes on a moderately sized FastAPI codebase I maintain. The team (which includes Guido himself!) literally created a new python native compiler (mypyc) to try and improve performance of the tool. I like types in Python but it's early days compared to a more mature tool like Typescript. IMO it's pretty clear cut if you've spent significant time using both.

insanitybit 3y ago

You can't even represent `Json` in Python's type system because it would require a recursive type. edit: I think this is actually a Python type annotation limitation but it's possible that's mypy, although I think in 99% of cases those are fine to conflate (I have used other Python type systems).

dazzlefruit 3y ago
In VSCode (which uses PyRight/PyLance) and Python 3.10: JSONObject = None | str | int | bool | list["JSONObject"] | dict[str, "JSONObject"] # this type checks a: JSONObject = {"a": [1, 2, "7", True, {"false": None}]} # this doesn't type check b: JSONObject = {"a": [1, 2, "7", True, {"false": object()}]}
- insanitybit 3y ago
  Cool, guess they finally fixed this. Must've been in the last ~1 year, give or take. Of course, it relies on quoting your types, which is... a matter of taste, I suppose.
  - dazzlefruit 3y ago
    Quoting types that are defined later is a wart but it's not very bad. VSCode's UI will happily handle it as if the quotes weren't there.
  - npage97 3y ago
    You can also use from __future__ import annotations so the quotes become unnecessary. https://peps.python.org/pep-0563/ https://peps.python.org/pep-0563/
    - insanitybit 3y ago
      Does that work with recursive types? I have had mixed results with `from __future__ import annotations` personally, but I haven't written much Python in ~a year or so.

crabbone 3y ago

Surprise: all languages have types. Superior to TypeScript is neither a high bar, nor is this any kind of objective metric. I don't know why sum types are a blessing, also I don't know why pattern matching makes anything better. I can name a lot of problems with Python, and I'm sure that libraries isn't the only one. For example, for no reason, Python has multiple unrelated mechanisms to manage program state (object, clojures, context managers). Or, here's another one: it has multiple public API for dealing with filesystem (i.e. os.path and pathlib), both of which are all sorts of bad, but just the fact that it has two, where one would do is bad. It's not possible to make static typing ineffective. Static typing is a given, it happens in the virtue of you having a program. You may argue that it doesn't exist if unobserved in the same way how a tree that falls in the forest doesn't really fall if unnoticed. But, really, it's there, and it's there in every language. You cannot make it ineffective. It's like making centimeters ineffective -- I would struggle to imagine what that may possibly mean.

dazzlefruit 3y ago
Why is pathlib bad? Edit: I'm asking because pathlib is as good as a Python lib could be for me. Path manipulations are extremely clear and always safe. What more do you need?
- Izkata 3y ago
  I'm guessing verbosity? It also reads like they don't know why pathlib exists and assume they were created at the same time. os.path came first, often works by poking the filesystem directly even when it doesn't seem like it needs to (vague memory, not completely certain), and I believe has os-specific quirks (so code won't necessarily work without changes). pathlib was created later as a pure-python implementation that allows for manipulation paths without touching the filsystem except when you explicitly tell it to. Because it's also pure python I don't think it has any os-specific quirks either, but I haven't explored it in depth. Code should work across operating systems without changes. I think I also remember at one point people talking about completely replacing os.path with pathlib, or at least gutting os.path to the essentials that wouldn't work as part of pathlib.
- 3y ago

Timon3 3y ago

> Python not only has types but it's type system is superior to typeScript. I strongly disagree. It might be better at some things, but it's much worse at others. Many functions can't be accurately typed (try, for example, to make a well-typed function that concatenates two arbitrary fixed-size tuples), and as far as I know generic type transformations can't be implemented (random example "this type takes a Dict[str, Any] and returns an object with each key turned into a function").

dazzlefruit 3y ago
For the tuple example: from typing import TypeVar T, U, V, W = TypeVar('T'), TypeVar('U'), TypeVar('V'), TypeVar('W') def concatenate(a: tuple[T, U], b: tuple[V, W]) -> tuple[T, U, V, W]: return a + b For the generic type transformation example, I'm not sure what you mean: from typing import Any, Callable Transformer = Callable[[dict[str, Any]], dict[Callable, Any]] This seems to match your question but it's really weird.
- Timon3 3y ago
  Your tuple example only works if both tuples have two elements. I specifically mentioned arbitrary fixed-size tuples (as in, tuples with an arbitrary non-variable length). Your generic type transformation example also doesn't come close to what Typescript does. The resulting dict will not have known keys based on the keys of the input dict. In Typescript I can write a function that takes an object with known keys, and it returns an object with those same keys having their values mapped to a different type, with the keys still known. I threw together a quick example - just look at the type of resultA/resultB by hovering over the variables[0]. But both are great examples - they are probably the closest you can get in Python, and they are so far removed from the thing I want to represent that they are completely useless. [0]: https://www.typescriptlang.org/play?#code/MYewdgzgLgBAhjAvDA3gKBjAZiEAuGKAJwFcBTAGgxgCM4iCs4AbCS6ugLwLBOeaoBfNGlCRYNJKmo58MACwAmKpjoMYAIgAWZfiBgB3EEWYATDStpxuMANoBdISKwkwwKAEtwhInEg4iAFsAeRoAKzJ3AB4AFRgyAA8oMjBTCBgAJUjjUyjoIg8wAHMKeDAATwA+SoAKEHCCGIBKAhQ7AGkYQpgAazJykCwYGPsCGqakSuHbdvsYQWlMIjIoEiIwGAB6TcIQUxA0YVFwaBhliD4oAEEpYj8IAJDwyKgauCbj8TOyC+YoACFbr5-MYnhF3DUaE0gA https://www.typescriptlang.org/play?#code/MYewdgzgLgBAhjAvDA...

timeon 3y ago

> sum types Even PHP have those now. TypeScript is lagging here. Hopefully, they will include it too one day.