5 ms·

Typed python is extremely ugly and frustrating. Does anyone have any good advice on doing it well? It seems like every library has their own system and doing an

by aabhay 4y ago

Typed python is extremely ugly and frustrating. Does anyone have any good advice on doing it well? It seems like every library has their own system and doing any kind of casting just to make the linter be quiet is such a chore.

benreesman 4y ago
Check out https://github.com/google/pytype https://github.com/google/pytype
- LtWorf 4y ago
  Use mypy. More mature.
VectorLock 4y ago
To me it seems like the ugliest parts of every language is the parts dealing with anything but the most simple types. When langs start introducing things like generics, then things really get gruesome. Thats why I always personally enjoyed duck typing.
- mrkeen 4y ago
  > Thats why I always personally enjoyed duck typing. Static or dynamic? You will ask a non-duck to quack. Do you want to find out before or after you start your application?
  - VectorLock 4y ago
    If you care if it can quack, you see if it can quack.
zo1 4y ago
If you're doing casting its probably a code smell and good indicator of something being off, or you're doing something too exotic. I'd say this applies a good amount to normal compiled languages too. To do types well, I'd recommend constraining as much as possible. E.g. if a library gives you a union of 5 possible return types, just type it as one of them that you know you'll get and don't let that "complexity" propagate further into your code base. Likewise if you're wrapping a lib function that can take 3 levels worth of complex union or umpteen varargs, don't let that bleed through in your function signature "just in case". And most crucial advice. Don't use Google's type checker pytypes. Or any other type checker for that matter other than Pycharms built-in one and mypy. Don't faff about with vscode either. Pycharm will make your python type hinting journey a pleasant experience (barring some generics and OOP corner case scenarios.)
- drewm1980 4y ago
  I agree. It is not perfect, but if pycharm can't figure out the type of an object, humans can't be expected to either.
- dragonwriter 4y ago
  > Or any other type checker for that matter other than Pycharms built-in one and mypy. Don’t faff about with vscode either. Eh, I’m not getting different editors for different languages (coding, documentation, and otherwise) used in the same project, and IntelliJ doesn’t have nice tooling for everything I need that VSCode does. Not sure how good Pycharm’s typechecking is, but pyright is, IME, usually better than mypy, and VSCode lets me belt-and-suspenders both of those if I choose (I did for a while, between being pure mypy and being pure pyright).
  - AdamN 4y ago
    PyCharm will be a big upgrade over VSCode for any full sized project trying to use type hints (and really for any Python project)
drewm1980 4y ago
Use a powerful IDE and lower your expectations. Python is halfway through a decades long transition to being a statically typed language, but there is no consensus that that's where we're going, so a minority of libraries will be a pain in the typechecker for the foreseeable future.
ReflectedImage 4y ago
There is no point in statically typed Python, it's useless. Just a lot of people from other programming languages coming in and trying to make the language more familiar to them.
- LtWorf 4y ago
  I moved from python2 to python3 to typed python3. It makes refactor much easier, I can easily understand what parameter a function wants, without having to read the docstring or worse, the body of the function. typecheckers do find a lot of errors that would otherwise be runtime errors.
  - ReflectedImage 4y ago
    Typed Python code on average takes two times the time to develop and contains two times the number of bugs per delivered software feature. It's bad, really really bad. Refactoring can be done just as well via a good IDE and unit testing. Using typechecking creates far more errors then it finds. They are a necessary evil in compiled languages. It's been measured that it creates more errors. That is not open for debate.
    - snapcaster 4y ago
      What is this based on? I have a lot of trouble believing untyped python code has half the bugs of typed code being someone who has written and read a lot of both
      - ReflectedImage 4y ago
        Actual measurements. I don't think you should be surprised. Untyped Python code is a lot shorter and more concise than typed Python code. The easiest way by far to reduce the bug count is to reduce the lines of code.
        snapcaster 4y ago
LtWorf 4y ago
> It seems like every library has their own system Well there are like 3 or 4 checkers existing. Then there's pydantic which needs a mypy plugin because it uses the types in a very non-standard way. But I use typedload (which I wrote) so that's not an issue for me. Other than pydantic I've just encountered libraries without type definitions, or done properly. Perhaps the fact that I tend to avoid adding dependencies helps me there.
ActorNightly 4y ago
>Does anyone have any good advice on doing it well? Yes, don't try to shove all your code into OOP, and you will be fine.
hbrn 4y ago
I've seen typing go wrong more than once and I think it always follows the same dumb non-nuanced pattern: "typing is great, therefore we should do it everywhere!" Anyone following this approach is an idiot, it's like prescribing a very niche diet to everybody. If you want it to be useful instead of doing it everywhere, you should limit it as much as possible. Find a few isolated places where you want types and limit analyzer to this area only (btw, it is entirely possible that there are no places like this in your code - that's a good thing). You can always extend the area that's covered by static analyzer, but you can never shrink it (at least I've never seen it happen). If you don't do this, typing becomes viral and you will soon be doing typing for the sake of typing and fighting your tools instead of extracting value from them.

by aabhay 4y ago

benreesman 4y ago

Check out https://github.com/google/pytype https://github.com/google/pytype

LtWorf 4y ago
Use mypy. More mature.

VectorLock 4y ago

To me it seems like the ugliest parts of every language is the parts dealing with anything but the most simple types. When langs start introducing things like generics, then things really get gruesome. Thats why I always personally enjoyed duck typing.

mrkeen 4y ago
> Thats why I always personally enjoyed duck typing. Static or dynamic? You will ask a non-duck to quack. Do you want to find out before or after you start your application?
- VectorLock 4y ago
  If you care if it can quack, you see if it can quack.

zo1 4y ago

If you're doing casting its probably a code smell and good indicator of something being off, or you're doing something too exotic. I'd say this applies a good amount to normal compiled languages too. To do types well, I'd recommend constraining as much as possible. E.g. if a library gives you a union of 5 possible return types, just type it as one of them that you know you'll get and don't let that "complexity" propagate further into your code base. Likewise if you're wrapping a lib function that can take 3 levels worth of complex union or umpteen varargs, don't let that bleed through in your function signature "just in case". And most crucial advice. Don't use Google's type checker pytypes. Or any other type checker for that matter other than Pycharms built-in one and mypy. Don't faff about with vscode either. Pycharm will make your python type hinting journey a pleasant experience (barring some generics and OOP corner case scenarios.)

drewm1980 4y ago
I agree. It is not perfect, but if pycharm can't figure out the type of an object, humans can't be expected to either.
dragonwriter 4y ago
> Or any other type checker for that matter other than Pycharms built-in one and mypy. Don’t faff about with vscode either. Eh, I’m not getting different editors for different languages (coding, documentation, and otherwise) used in the same project, and IntelliJ doesn’t have nice tooling for everything I need that VSCode does. Not sure how good Pycharm’s typechecking is, but pyright is, IME, usually better than mypy, and VSCode lets me belt-and-suspenders both of those if I choose (I did for a while, between being pure mypy and being pure pyright).
- AdamN 4y ago
  PyCharm will be a big upgrade over VSCode for any full sized project trying to use type hints (and really for any Python project)

drewm1980 4y ago

Use a powerful IDE and lower your expectations. Python is halfway through a decades long transition to being a statically typed language, but there is no consensus that that's where we're going, so a minority of libraries will be a pain in the typechecker for the foreseeable future.

ReflectedImage 4y ago

There is no point in statically typed Python, it's useless. Just a lot of people from other programming languages coming in and trying to make the language more familiar to them.

LtWorf 4y ago
I moved from python2 to python3 to typed python3. It makes refactor much easier, I can easily understand what parameter a function wants, without having to read the docstring or worse, the body of the function. typecheckers do find a lot of errors that would otherwise be runtime errors.
- ReflectedImage 4y ago
  Typed Python code on average takes two times the time to develop and contains two times the number of bugs per delivered software feature. It's bad, really really bad. Refactoring can be done just as well via a good IDE and unit testing. Using typechecking creates far more errors then it finds. They are a necessary evil in compiled languages. It's been measured that it creates more errors. That is not open for debate.
  - snapcaster 4y ago
    What is this based on? I have a lot of trouble believing untyped python code has half the bugs of typed code being someone who has written and read a lot of both
    - ReflectedImage 4y ago
      Actual measurements. I don't think you should be surprised. Untyped Python code is a lot shorter and more concise than typed Python code. The easiest way by far to reduce the bug count is to reduce the lines of code.
      - snapcaster 4y ago

LtWorf 4y ago

> It seems like every library has their own system Well there are like 3 or 4 checkers existing. Then there's pydantic which needs a mypy plugin because it uses the types in a very non-standard way. But I use typedload (which I wrote) so that's not an issue for me. Other than pydantic I've just encountered libraries without type definitions, or done properly. Perhaps the fact that I tend to avoid adding dependencies helps me there.

ActorNightly 4y ago

>Does anyone have any good advice on doing it well? Yes, don't try to shove all your code into OOP, and you will be fine.

hbrn 4y ago

I've seen typing go wrong more than once and I think it always follows the same dumb non-nuanced pattern: "typing is great, therefore we should do it everywhere!" Anyone following this approach is an idiot, it's like prescribing a very niche diet to everybody. If you want it to be useful instead of doing it everywhere, you should limit it as much as possible. Find a few isolated places where you want types and limit analyzer to this area only (btw, it is entirely possible that there are no places like this in your code - that's a good thing). You can always extend the area that's covered by static analyzer, but you can never shrink it (at least I've never seen it happen). If you don't do this, typing becomes viral and you will soon be doing typing for the sake of typing and fighting your tools instead of extracting value from them.