1. Give up on pre-commit. It would be nice if it just worked, but it doesn't. Just make a type checking script and run it as the first thing in CI.
2. Use Pyright, not Mypy. It's much much better.
3. You can start with a very loose config and gradually make it stricter.
4. Make liberal use of `type: ignore` (and add TODOs to make it clear they're not intentional).
5. You can also make an alias for Any and use that for types that you intend to figure out but haven't yet.
Typing Python that wasn't written with type hints in the first place is always going to be a complete nightmare though. People that write untyped Python tend to write it in highly dynamic ways and Python's type hints often aren't expressive enough to describe them (e.g. they only very recently added support for properly typing kwargs).
> Typing Python that wasn't written with type hints in the first place is always going to be a complete nightmare though
Couldn’t agree more. I joined a new team and recently finished converting a 20K line repo. It was a grueling grind to get mypy running in strict mode.
I’m continually finding that a huge benefit of typed python code isn’t autocomplete or catching bad argument passing, but preventing developers from creating patterns that are unmaintainable.
If your code is too complex to type correctly, its probably too complex in general :)
> If your code is too complex to type correctly, its probably too complex in general :)
Ha I definitely agree with that. There are some exceptions where you want to do a reasonable thing that the types just aren't expressive enough for, but in general if you can't explain it so the type checker understands then your coworkers won't either.
> 1. Give up on pre-commit. It would be nice if it just worked, but it doesn't. Just make a type checking script and run it as the first thing in CI.
I’ve been slowly reaching this conclusion after a few years of running into little issues. We run our pre-commit hooks as their own CI test via tox. I’m beginning to feel both tox and pre-commit are more trouble than they are worth, and most of that trouble comes from them trying to create and manage their own mini-environments. Which is never going to match having explicit envs, state, and deps via docker files that can be granularity inspected and/or deployed to other contexts.
> 2. Use Pyright, not Mypy. It's much much better.
Does this work well with pycharm? I think I looked into this a while ago and it seemed really tightly coupled to VSC. And I know some people love it, but I’ve found VSC’s config for linting/type checks/ auto formatting to be a complete confusing mess, and that it is generally much slower and buggier than pycharm (e.g. it will highlight errors that don’t exist, not update syntax highlighting instantly, etc).
I know it’s entirely possible that it’s just me who is an idiot here, but I’ve set up VSC on like 3 separate machines now in the last few years and it invariably ends up in some weird broken state, especially regarding highlighting code performantly and correctly using the same rules we have in CI.
Nah pre-commit is great for lots of quick checks (formatting, trailing whitespace, linting shell scripts etc), it's just that type checking Python requires the Python dependencies to be already installed and that means setting up a venv and installing stuff and that's just a bit too complex.
> Does this work well with pycharm? I think I looked into this a while ago and it seemed really tightly coupled to VSC.
Possibly not. You can definitely run it from the command line without VSCode since Pyright the type checker is open source. The VSCode Python LSP server Pylance is closed source though (this provides additional features beyond type checking like completion and refactoring).
Haven't used Pycharm for decades but I'd guess it has its own thing.
1. Give up on pre-commit. It would be nice if it just worked, but it doesn't. Just make a type checking script and run it as the first thing in CI.
2. Use Pyright, not Mypy. It's much much better.
3. You can start with a very loose config and gradually make it stricter.
4. Make liberal use of `type: ignore` (and add TODOs to make it clear they're not intentional).
5. You can also make an alias for Any and use that for types that you intend to figure out but haven't yet.
Typing Python that wasn't written with type hints in the first place is always going to be a complete nightmare though. People that write untyped Python tend to write it in highly dynamic ways and Python's type hints often aren't expressive enough to describe them (e.g. they only very recently added support for properly typing kwargs).