3 ms·

I’d probably agree with you 5 years ago, but in those 5 years typescript has shown that you can take a completely dynamic language, add a very powerful and well

by baq 3y ago

I’d probably agree with you 5 years ago, but in those 5 years typescript has shown that you can take a completely dynamic language, add a very powerful and well thought out type system and the resulting language is so much better for non-trivial projects. So if you ask me, who has been programming Python since before new-style classes, if types make sense for Python, the answer is a resounding ‘yes’: just steal as much typescript typing as possible.

LarsDu88 3y ago
And not only that, but you can take that statically typed code and build JIT compilers on top of them
BiteCode_dev 3y ago
I wish we'd steal more. TS type systel and syntax is much better that what we have. And I hope one day iter[] and callable[] will be made available, cause importing typing sucks.
Chris_Newton 3y ago
At first glance, JavaScript/TypeScript and Python seem like similar cases, but in practice, I have never found them to be so. The JS/TS community has enthusiastically adopted static typing, to the point where (a) the type system in TypeScript is reasonably clean and intuitive for everyday work, (b) almost every major library uses static types and specifies them in its documentation, (c) almost all major tools and development environments pick them up and work well with them, and probably as a result of those things, (d) almost everyone now uses static types extensively, at least for new development. The Python community seems far more hesitant. I don’t know why. Maybe it’s because we’d just had such a long transition from Python 2 to Python 3 and introducing static typing feels like another big change? Maybe it’s because Python’s static type system simply hasn’t been as clean and tidy as TypeScript’s, particularly before the recent generics changes in 3.12? Whatever the reason, in practice none of (a)–(d) above reliably holds in the Python world. Personally I do still prefer to use static types in new Python code, but it’s frustrating and often needlessly time-consuming when popular libraries don’t.
- deleted 3y ago
  [deleted]
- zokier 3y ago
  While there are countless cultural and technical reasons why TS ended up more successful than Python here, I think the single most significant aspect was that TS decided to go with structural system while Python went with nominal. While nominal systems in general are fairly popular and well-received, the chief thing here is that structural types match how the language was being already used. Especially for Python they had before embraced "duck typing" as their idiom and nominal types are in conflict with that.
  - trashburger 3y ago
    This is my single greatest complaint about Python's type system. Protocol should have always been the primary building block rather than just being relegated to something you use for "duck typing". Subtyping fits much better with things like the dynamic approach of the Django ORM, for example.
    - alanwreath 3y ago
      Not sure what you mean, while it’s true that it would have been nice that Protocols were always the primary building block, as of python 3.8 they _can_ be depending on your use of Structural Typing https://peps.python.org/pep-0544/ https://peps.python.org/pep-0544/

by baq 3y ago

LarsDu88 3y ago

And not only that, but you can take that statically typed code and build JIT compilers on top of them

BiteCode_dev 3y ago

I wish we'd steal more. TS type systel and syntax is much better that what we have. And I hope one day iter[] and callable[] will be made available, cause importing typing sucks.

Chris_Newton 3y ago

At first glance, JavaScript/TypeScript and Python seem like similar cases, but in practice, I have never found them to be so. The JS/TS community has enthusiastically adopted static typing, to the point where (a) the type system in TypeScript is reasonably clean and intuitive for everyday work, (b) almost every major library uses static types and specifies them in its documentation, (c) almost all major tools and development environments pick them up and work well with them, and probably as a result of those things, (d) almost everyone now uses static types extensively, at least for new development. The Python community seems far more hesitant. I don’t know why. Maybe it’s because we’d just had such a long transition from Python 2 to Python 3 and introducing static typing feels like another big change? Maybe it’s because Python’s static type system simply hasn’t been as clean and tidy as TypeScript’s, particularly before the recent generics changes in 3.12? Whatever the reason, in practice none of (a)–(d) above reliably holds in the Python world. Personally I do still prefer to use static types in new Python code, but it’s frustrating and often needlessly time-consuming when popular libraries don’t.

deleted 3y ago
[deleted]
zokier 3y ago
While there are countless cultural and technical reasons why TS ended up more successful than Python here, I think the single most significant aspect was that TS decided to go with structural system while Python went with nominal. While nominal systems in general are fairly popular and well-received, the chief thing here is that structural types match how the language was being already used. Especially for Python they had before embraced "duck typing" as their idiom and nominal types are in conflict with that.
- trashburger 3y ago
  This is my single greatest complaint about Python's type system. Protocol should have always been the primary building block rather than just being relegated to something you use for "duck typing". Subtyping fits much better with things like the dynamic approach of the Django ORM, for example.
  - alanwreath 3y ago
    Not sure what you mean, while it’s true that it would have been nice that Protocols were always the primary building block, as of python 3.8 they _can_ be depending on your use of Structural Typing https://peps.python.org/pep-0544/ https://peps.python.org/pep-0544/