4 ms·

Ask HN: Will we see a TypeScript for Python?

11 points by rrishi 4y ago

Is there a need for such a thing like JS needed it? Is it viable?

PaulHoule 4y ago
Python has an optional typing system which helps your IDE complete things and can be checked with tools like https://mypy.readthedocs.io/en/stable/index.html https://mypy.readthedocs.io/en/stable/index.html Plus there are compilers which can make faster code if you add static types https://cython.readthedocs.io/en/latest/src/quickstart/cythonize.html https://cython.readthedocs.io/en/latest/src/quickstart/cytho...
deleted 4y ago
[deleted]
peruvian 4y ago
Python 3 has types and you can use Pydantic for validation. https://docs.pydantic.dev https://docs.pydantic.dev
- mola 4y ago
  Isn't pydantic only for runtime validation?
- postpawl 4y ago
  Not just Pydantic. Mypy is more commonly used and has something called mypyc that can compile your typed python code into C.
jasfi 4y ago
If you consider a language besides Python itself (which has optional typing), Nim could be an option, as the syntax is similar.
- jstx1 4y ago
  That's a completely different thing though. Python <> Nim is nothing like JS <> TS. And who cares about the syntax if you're using a completely different language, you can pick any typed language at that point.
user3939382 4y ago
In the abstract we have Psalm for PHP which I think is likely to eventually get rolled into PHP’s native type system. It’s so robust the major IDEs haven’t fully implemented it yet. It doesn’t turn PHP into Haskell or anything but huge swaths of bugs are eliminated.
otabdeveloper4 4y ago
Probably never. Modern Python is a joke, and so are attempts at to typify it like mypy.
- nickphx 4y ago
  I've built several multi-million dollar a year businesses using python.. It's hilarious.
  - otabdeveloper4 4y ago
    And multi-million dollar businesses are built on Excel every day. Your point is what exactly?
nilsbunger 4y ago
Python typing is optional and only checked statically, just like typescript typing. What else would a “Typescript for Python” add?
speedgoose 4y ago
As other mentioned, Python has already some tools around strong typing. However they aren’t as extensive as TypeScript is to JavaScript. The community is also not much into types so you don’t have collections like Definitely Typed. But the need exists and I guess it’s a matter of time until a tool becomes as popular and complete as typescript.
- ameliaquining 4y ago
  https://github.com/python/typeshed https://github.com/python/typeshed is Python's equivalent of DefinitelyTyped. I'm not 100% sure why it's not more of a popular thing the way DefinitelyTyped is; I think there might, to some extent, be different attitudes around the appropriateness of having third-party typings for packages, when the actual maintainer of the package isn't interested in providing first-party ones.
hot_gril 4y ago
JS doesn't need TypeScript. When's the last time TS saved your JS project from disaster?
- cultofmetatron 4y ago
  typescript isn't about saving a js project. its best when you get it at the beginning. where you can provide hints to your debugger and have type checkers that catch bugs proactively. you can just as easily any your way out of all the benefits.
  - hot_gril 4y ago
    Sorry if I'm being pedantic, was just responding to OP's phrasing of static typing being a "need" despite JS and Py having come so far without it. I'd say it's situational at best, and "you can turn it off" is probably TS's best feature. If you're starting with TS, you can't really tell if it's useful or just a chore. I started a large Node project that a teammate moved to TS, saying the same thing about any that you did. I thought it'd be like Rust where it figures out the type for you, but no, any spreads. We replaced all those with explicit types, and I was writing fresh code in TS, but I realized it wasn't preventing any bugs that our integration tests wouldn't catch. It was just wasting my time with verbose types for things like SQL result rows that you could obviously tell were fine from the context. The other guy spent a ton of time fixing our build/deployment for TS, something that's taken lightly until you actually do it. The project was pivoted for unrelated reasons, and I was left alone with it. I finally took it back to JS when I reached my last straw with TS, finding that it breaks the built-in Node profiler. Overall my velocity improved going back to JS. If TS were truly useful in that scenario, it'd be worth its weight for the reduced bugs that cost time to fix, but it wasn't.
findjashua 4y ago
pyright
abeppu 4y ago
It's true that python has support for typing, and I do find that mypy helps produce better python code. But I think a meaningful issue is that python's rich ecosystem of datascience and ML tooling often is at odds with meaningful type annotations. Roughly, you can end up with signatures that indicate that a value is a DataFrame or an ndarray or whatever, but there are a bunch of implicit assumptions on what columns are defined, or what how the shapes of two ndarrays line up, etc. It's easy for a codebase to end up paying the upfront cost of providing annotations, but without actually getting an improved ability to reason about or refactor code.

11 points by rrishi 4y ago

Is there a need for such a thing like JS needed it? Is it viable?

Python has an optional typing system which helps your IDE complete things and can be checked with tools like https://mypy.readthedocs.io/en/stable/index.html https://mypy.readthedocs.io/en/stable/index.html Plus there are compilers which can make faster code if you add static types https://cython.readthedocs.io/en/latest/src/quickstart/cythonize.html https://cython.readthedocs.io/en/latest/src/quickstart/cytho...

deleted 4y ago

[deleted]

peruvian 4y ago

Python 3 has types and you can use Pydantic for validation. https://docs.pydantic.dev https://docs.pydantic.dev

mola 4y ago
Isn't pydantic only for runtime validation?
postpawl 4y ago
Not just Pydantic. Mypy is more commonly used and has something called mypyc that can compile your typed python code into C.

jasfi 4y ago

If you consider a language besides Python itself (which has optional typing), Nim could be an option, as the syntax is similar.

jstx1 4y ago
That's a completely different thing though. Python <> Nim is nothing like JS <> TS. And who cares about the syntax if you're using a completely different language, you can pick any typed language at that point.

user3939382 4y ago

In the abstract we have Psalm for PHP which I think is likely to eventually get rolled into PHP’s native type system. It’s so robust the major IDEs haven’t fully implemented it yet. It doesn’t turn PHP into Haskell or anything but huge swaths of bugs are eliminated.

otabdeveloper4 4y ago

Probably never. Modern Python is a joke, and so are attempts at to typify it like mypy.

nickphx 4y ago
I've built several multi-million dollar a year businesses using python.. It's hilarious.
- otabdeveloper4 4y ago
  And multi-million dollar businesses are built on Excel every day. Your point is what exactly?

nilsbunger 4y ago

Python typing is optional and only checked statically, just like typescript typing. What else would a “Typescript for Python” add?

speedgoose 4y ago

As other mentioned, Python has already some tools around strong typing. However they aren’t as extensive as TypeScript is to JavaScript. The community is also not much into types so you don’t have collections like Definitely Typed. But the need exists and I guess it’s a matter of time until a tool becomes as popular and complete as typescript.

ameliaquining 4y ago
https://github.com/python/typeshed https://github.com/python/typeshed is Python's equivalent of DefinitelyTyped. I'm not 100% sure why it's not more of a popular thing the way DefinitelyTyped is; I think there might, to some extent, be different attitudes around the appropriateness of having third-party typings for packages, when the actual maintainer of the package isn't interested in providing first-party ones.

hot_gril 4y ago

JS doesn't need TypeScript. When's the last time TS saved your JS project from disaster?

cultofmetatron 4y ago
typescript isn't about saving a js project. its best when you get it at the beginning. where you can provide hints to your debugger and have type checkers that catch bugs proactively. you can just as easily any your way out of all the benefits.
- hot_gril 4y ago
  Sorry if I'm being pedantic, was just responding to OP's phrasing of static typing being a "need" despite JS and Py having come so far without it. I'd say it's situational at best, and "you can turn it off" is probably TS's best feature. If you're starting with TS, you can't really tell if it's useful or just a chore. I started a large Node project that a teammate moved to TS, saying the same thing about any that you did. I thought it'd be like Rust where it figures out the type for you, but no, any spreads. We replaced all those with explicit types, and I was writing fresh code in TS, but I realized it wasn't preventing any bugs that our integration tests wouldn't catch. It was just wasting my time with verbose types for things like SQL result rows that you could obviously tell were fine from the context. The other guy spent a ton of time fixing our build/deployment for TS, something that's taken lightly until you actually do it. The project was pivoted for unrelated reasons, and I was left alone with it. I finally took it back to JS when I reached my last straw with TS, finding that it breaks the built-in Node profiler. Overall my velocity improved going back to JS. If TS were truly useful in that scenario, it'd be worth its weight for the reduced bugs that cost time to fix, but it wasn't.

findjashua 4y ago

pyright

abeppu 4y ago

It's true that python has support for typing, and I do find that mypy helps produce better python code. But I think a meaningful issue is that python's rich ecosystem of datascience and ML tooling often is at odds with meaningful type annotations. Roughly, you can end up with signatures that indicate that a value is a DataFrame or an ndarray or whatever, but there are a bunch of implicit assumptions on what columns are defined, or what how the shapes of two ndarrays line up, etc. It's easy for a codebase to end up paying the upfront cost of providing annotations, but without actually getting an improved ability to reason about or refactor code.