3 ms·

This is a weakness of the Python typing system and not necessarily of individual typecheckers. Pyright has a policy of only implementing what's standardized, an

This is a weakness of the Python typing system and not necessarily of individual typecheckers. Pyright has a policy of only implementing what's standardized, and the Python type system is simply inadequate to annotate most real world Python code out there. It's been years now and something as basic as properly typing kwargs is still not supported. Ty could solve this if they rebel and decide to ignore the Python typing standards, which I honestly would appreciate, but if they take the sensible approach and follow the standards, it won't change anything.

Spivak 1y ago
> properly typing kwargs is still not supported. I've been typing them with TypedDict for a while now and it's been fine. What can't you do?
- reubenmorais 1y ago
  Two examples that come to mind are: https://discuss.python.org/t/pep-692-using-typeddict-for-more-precise-kwargs-typing/17314 https://discuss.python.org/t/pep-692-using-typeddict-for-mor... and: https://github.com/python/typing/issues/1252 https://github.com/python/typing/issues/1252
9dev 1y ago
Python code feels like back in the day when JavaScript was typed using JSDoc comments, and libraries would use all kinds of fantastical object shapes for their option parameters, so users could pass "just about anything" and it would work. You would never know how to configure an Express app without digging through the documentation, for example. I loathe the Python convention of just using kwargs instead of clearly annotated parameters; most libraries don't even have doc comments in the code, so you're really required to look up the documentation, hope that it actually describes the method you're interested in and contains more than stuff like "foo: the foo to use"—or fall back to rummaging in the library intestines to figure out how it works. It's pathetic.
- oxcabe 1y ago
  Sometimes, though, you may get lucky, and find some tests for the code you want to use! On a more serious note, I can't even blame library devs as long as they try. Type "hints" often are anything but _just_ hints. Some are expected to be statically checked; some may alter runtime behavior (e.g. the @overload decorator). It's like the anti-pattern of TypeScript's enums laid out here and there, and it's even harder to notice such side-effects in Python.
- cadu2 1y ago
  I'm not sure into what kind of industry you're in, but having most functions as (args, *kwargs) is not the way I deal with most of my code and the libraries I work at all (backend development). Everything is typed fully. Maybe you're in a niche spot, or using scientist-based code. I've seen plenty of trainwrecks in 'conda-only' ""libraries"" done by scientists. Maybe that's the niche you're at?

Spivak 1y ago

> properly typing kwargs is still not supported. I've been typing them with TypedDict for a while now and it's been fine. What can't you do?

reubenmorais 1y ago
Two examples that come to mind are: https://discuss.python.org/t/pep-692-using-typeddict-for-more-precise-kwargs-typing/17314 https://discuss.python.org/t/pep-692-using-typeddict-for-mor... and: https://github.com/python/typing/issues/1252 https://github.com/python/typing/issues/1252

9dev 1y ago

Python code feels like back in the day when JavaScript was typed using JSDoc comments, and libraries would use all kinds of fantastical object shapes for their option parameters, so users could pass "just about anything" and it would work. You would never know how to configure an Express app without digging through the documentation, for example. I loathe the Python convention of just using kwargs instead of clearly annotated parameters; most libraries don't even have doc comments in the code, so you're really required to look up the documentation, hope that it actually describes the method you're interested in and contains more than stuff like "foo: the foo to use"—or fall back to rummaging in the library intestines to figure out how it works. It's pathetic.

oxcabe 1y ago
Sometimes, though, you may get lucky, and find some tests for the code you want to use! On a more serious note, I can't even blame library devs as long as they try. Type "hints" often are anything but _just_ hints. Some are expected to be statically checked; some may alter runtime behavior (e.g. the @overload decorator). It's like the anti-pattern of TypeScript's enums laid out here and there, and it's even harder to notice such side-effects in Python.
cadu2 1y ago
I'm not sure into what kind of industry you're in, but having most functions as (args, *kwargs) is not the way I deal with most of my code and the libraries I work at all (backend development). Everything is typed fully. Maybe you're in a niche spot, or using scientist-based code. I've seen plenty of trainwrecks in 'conda-only' ""libraries"" done by scientists. Maybe that's the niche you're at?