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.
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.)
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).
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?
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.
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.
Yes, don't try to shove all your code into OOP, and you will be fine.
Just a lot of people from other programming languages coming in and trying to make the language more familiar to them.
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.
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.
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.
It only seems to say that typed code takes longer to write and is longer. It doesn't seem to say that typed code has more bugs, nor does it compare typed Python with untyped Python.
This is a claim I see repeated over and over without much evidence to support it. In my experience type checkers find a lot of errors that would still be found at later stages and a lot of tiny errors that don't matter and can be dealt with via much cheaper tools.
Shorter feedback cycle is nice, and occasionally it does catch a real bug, but the benefits of static typing are vastly overblown.
There probably are teams where typecheckers do catch a lot of important runtime errors. Those are the teams with a horrible engineering culture. In those environments typecheckers are a bandaid, not a cure. If anything, they are hiding the real problem: you shouldn't give a perfume to someone who doesn't shower.