5 ms·

I'm really excited for where Python's static typing is heading! I doubt that typing Python code will ever become as ergonomic as typescript, simply because typ

I'm really excited for where Python's static typing is heading! I doubt that typing Python code will ever become as ergonomic as typescript, simply because typescript doesn't have the constraint of modifying the syntax of it's "target language" (JS) when it wants to add a feature or whatever, whereas typed python must still be Python, and syntactic changes therefore need to be added much more conservatively. But still, the typing story is improving before my very eyes with every release, and given that Python types are actually available at runtime (allowing for things like pydantic and FastAPI), and that Python has massive adoption in the ML space, all this is making Python a very enticing language to get back to using!

cdrini 4y ago
I love that Python has types available at runtime! The ability to have those type-generated CLIs or APIs is fantastic. I learned from this article about functools.singledispatch, and can't wait to use it. I've always wanted something like in typescript! But `functools.singledispatch` is just not possible in TS. I think working with dicts is still a little clunky in python, and there are some rough edges (eg mypy being a little weaker), but I genuinely think I like types in python better than TS!
- davidatbu 4y ago
  > I genuinely think I like types in python better than TS! That's a step further than I'm willing to go :D. For example, the other day, I was able to do settingToToggle: KeysWithTypeOf<SomeObject, boolean> which (after properly defining `KeysWithTypeOf`) allowed me to specify that `settingToToggle` should be a string literal that is a key on `SomeObject` whose corresponding value is a boolean. Typescript comes closest to fully letting me express my intentions statically and curtly, and while I hope Python's static typing will grow to be as expressive as Typescript, I think that day is still afar off.
  - cdrini 4y ago
    For me the remaining pieces for Python are much more attainable than the missing pieces for typescript. I think basically all the helper TS things (eg KeyOf, etc) are addable to Python. Runtime types are not addable to TS. It goes against some of the core principles of TS. But I agree there are loads of missing features in Python :)
    - davidatbu 4y ago
      You might be (very) interested in this project then: https://deepkit.io/ https://deepkit.io/ The guy behind it made a PR to typescript proposing runtime availability of types[0], got rejected, and got going on it by himself. And he already has PoC libraries with the (early) equivalents of Pydantic/FastAPI/SQLModel (using runtime types for (de)serialization). I really hope this experiment works out and that it gains traction, because it's a massive value add to TS IMO. [0] https://github.com/microsoft/TypeScript/issues/47658 https://github.com/microsoft/TypeScript/issues/47658
      - cdrini 4y ago
        Oh wow! You are correct, I am very interested in it! Thanks for sharing! Honestly on most of my personal projects, I only use typescript via the jsdoc interface. I just never felt the need to get to 100% type safety for most projects. And I never liked how the types lend themselves to a style of programming which typescript can't support due to lack of runtime typing (eg multiple dispatch, function overloading, serialisation, etc). This project looks very cool, and shifts those tradeoffs for me! I'm going to need to give it a whirl!
- kortex 4y ago
  What do you use for type-generated CLIs? I've been using Pydantic for config parsing and Cleo for CLI, but I don't yet have a good solution for hoisting/injection of CLI arguments alongside env/file configs. I really want a declarative solution like Rust's Clap library, but I haven't yet found anything like it out there.
  - cdrini 4y ago
    Unfortunately I couldn't find a good package either, so ended up rolling my own script, FnToCLI https://github.com/internetarchive/openlibrary/blob/ccf1024667a27cf95193ccd08785dcb8e1676ba9/scripts/solr_builder/solr_builder/fn_to_cli.py https://github.com/internetarchive/openlibrary/blob/ccf10246... . It wasn't too hard to get the bones of it working, so if you want to build something similar with built-in env handling, that might not be too bad! Under the hood it converts everything to argparse, so you can always use any complicated argparse options/etc if you want to. The closest package was Typer, by the creator of FastAPI, but it looked unmaintained, and didn't support Literal types! Or at least that was the case when I was investigating ~year ago.
IshKebab 4y ago
I'm not. There are still huge issues with it that Typescript and other statically typed languages don't have: 1. No way to fully type `args` and `kwargs` which are sadly common in Python code. 2. Type semantics aren't defined so there are multiple competing interpretations. Not great if your dependencies use one type checker and you use a different one. Not that that will matter because... 3. A depressingly huge part of the Python community doesn't get static typing so a ton of your dependencies won't have types. 4. The most popular type checker - MyPy - is full of bugs and deliberate unsoundness. Pyright is much better but also newer so lots of projects don't use it. I definitely wouldn't choose Python if I had a choice.
- davidatbu 4y ago
  > No way to fully type args and kwargs I think "parameter Specification Variables"[0] come pretty close to solving that no? I'd love to hear your take if you've used them before. > Type semantics aren't defined so there are multiple competing interpretations > The most popular type checker - MyPy - is full of bugs and deliberate unsoundness. 100% agreed. I hope Pyright "wins" as the dominant type checker, because like you said, it's MUCH better in every aspect. > A depressingly huge part of the Python community doesn't get static typing so a ton of your dependencies won't have types. 100%. I have so many half hearted attempts at typing my dependencies![1] > I definitely wouldn't choose Python if I had a choice. At this point, I'd have to agree, except of course for data science/ML things. [0] https://peps.python.org/pep-0612/ https://peps.python.org/pep-0612/ [1] https://github.com/davidatbu?tab=repositories&q=stubs&type=&language=&sort= https://github.com/davidatbu?tab=repositories&q=stubs&type=&...
  - ptx 4y ago
    One aspect of Pyright that seems decidedly not better is the 651 NPM dependencies [1] it apparently drags along. [1] https://github.com/microsoft/pyright/blob/main/package-lock.json https://github.com/microsoft/pyright/blob/main/package-lock....
    - davidatbu 4y ago
mountainriver 4y ago
Python types are available at runtime? Talking about __orig_class__? There are also breaking changes coming to annotations that may not work with pydantic I would actually consider this to be one of the weakest points of python types

cdrini 4y ago

I love that Python has types available at runtime! The ability to have those type-generated CLIs or APIs is fantastic. I learned from this article about functools.singledispatch, and can't wait to use it. I've always wanted something like in typescript! But `functools.singledispatch` is just not possible in TS. I think working with dicts is still a little clunky in python, and there are some rough edges (eg mypy being a little weaker), but I genuinely think I like types in python better than TS!

davidatbu 4y ago
> I genuinely think I like types in python better than TS! That's a step further than I'm willing to go :D. For example, the other day, I was able to do settingToToggle: KeysWithTypeOf<SomeObject, boolean> which (after properly defining `KeysWithTypeOf`) allowed me to specify that `settingToToggle` should be a string literal that is a key on `SomeObject` whose corresponding value is a boolean. Typescript comes closest to fully letting me express my intentions statically and curtly, and while I hope Python's static typing will grow to be as expressive as Typescript, I think that day is still afar off.
- cdrini 4y ago
  For me the remaining pieces for Python are much more attainable than the missing pieces for typescript. I think basically all the helper TS things (eg KeyOf, etc) are addable to Python. Runtime types are not addable to TS. It goes against some of the core principles of TS. But I agree there are loads of missing features in Python :)
  - davidatbu 4y ago
    You might be (very) interested in this project then: https://deepkit.io/ https://deepkit.io/ The guy behind it made a PR to typescript proposing runtime availability of types[0], got rejected, and got going on it by himself. And he already has PoC libraries with the (early) equivalents of Pydantic/FastAPI/SQLModel (using runtime types for (de)serialization). I really hope this experiment works out and that it gains traction, because it's a massive value add to TS IMO. [0] https://github.com/microsoft/TypeScript/issues/47658 https://github.com/microsoft/TypeScript/issues/47658
    - cdrini 4y ago
      Oh wow! You are correct, I am very interested in it! Thanks for sharing! Honestly on most of my personal projects, I only use typescript via the jsdoc interface. I just never felt the need to get to 100% type safety for most projects. And I never liked how the types lend themselves to a style of programming which typescript can't support due to lack of runtime typing (eg multiple dispatch, function overloading, serialisation, etc). This project looks very cool, and shifts those tradeoffs for me! I'm going to need to give it a whirl!
kortex 4y ago
What do you use for type-generated CLIs? I've been using Pydantic for config parsing and Cleo for CLI, but I don't yet have a good solution for hoisting/injection of CLI arguments alongside env/file configs. I really want a declarative solution like Rust's Clap library, but I haven't yet found anything like it out there.
- cdrini 4y ago
  Unfortunately I couldn't find a good package either, so ended up rolling my own script, FnToCLI https://github.com/internetarchive/openlibrary/blob/ccf1024667a27cf95193ccd08785dcb8e1676ba9/scripts/solr_builder/solr_builder/fn_to_cli.py https://github.com/internetarchive/openlibrary/blob/ccf10246... . It wasn't too hard to get the bones of it working, so if you want to build something similar with built-in env handling, that might not be too bad! Under the hood it converts everything to argparse, so you can always use any complicated argparse options/etc if you want to. The closest package was Typer, by the creator of FastAPI, but it looked unmaintained, and didn't support Literal types! Or at least that was the case when I was investigating ~year ago.

IshKebab 4y ago

I'm not. There are still huge issues with it that Typescript and other statically typed languages don't have: 1. No way to fully type `args` and `kwargs` which are sadly common in Python code. 2. Type semantics aren't defined so there are multiple competing interpretations. Not great if your dependencies use one type checker and you use a different one. Not that that will matter because... 3. A depressingly huge part of the Python community doesn't get static typing so a ton of your dependencies won't have types. 4. The most popular type checker - MyPy - is full of bugs and deliberate unsoundness. Pyright is much better but also newer so lots of projects don't use it. I definitely wouldn't choose Python if I had a choice.

davidatbu 4y ago
> No way to fully type args and kwargs I think "parameter Specification Variables"[0] come pretty close to solving that no? I'd love to hear your take if you've used them before. > Type semantics aren't defined so there are multiple competing interpretations > The most popular type checker - MyPy - is full of bugs and deliberate unsoundness. 100% agreed. I hope Pyright "wins" as the dominant type checker, because like you said, it's MUCH better in every aspect. > A depressingly huge part of the Python community doesn't get static typing so a ton of your dependencies won't have types. 100%. I have so many half hearted attempts at typing my dependencies![1] > I definitely wouldn't choose Python if I had a choice. At this point, I'd have to agree, except of course for data science/ML things. [0] https://peps.python.org/pep-0612/ https://peps.python.org/pep-0612/ [1] https://github.com/davidatbu?tab=repositories&q=stubs&type=&language=&sort= https://github.com/davidatbu?tab=repositories&q=stubs&type=&...
- ptx 4y ago
  One aspect of Pyright that seems decidedly not better is the 651 NPM dependencies [1] it apparently drags along. [1] https://github.com/microsoft/pyright/blob/main/package-lock.json https://github.com/microsoft/pyright/blob/main/package-lock....
  - davidatbu 4y ago

mountainriver 4y ago

Python types are available at runtime? Talking about __orig_class__? There are also breaking changes coming to annotations that may not work with pydantic I would actually consider this to be one of the weakest points of python types