Open cooperlees opened 5 months ago
There's a couple nasty things that need restructuring before we can add a loose mypy run, in particular the magic with namedtuple+partial for Error
which means that it can't be used as a type and any assignments to e.g. B005.methods
is a no-go.
I'd suggest doing something similar to how we do it in flake8-async, https://github.com/python-trio/flake8-async/blob/c977a2e8d471d474ef13ca9b746acdd63600ea52/flake8_async/base.py#L62
With making Error
a class with an abstract message
attribute, and then define all the error codes as subclasses.
For yielding the tuples to flake8 we can then implement __iter__
.
I love having types when developing, so whenever I contribute I don't mind adding types for whatever my contribution touches.
Thanks for calling this out. I expected this. I've never had a code base where adding typing has not unlocked some evil evil code. That's it's main advantage, if typing is hard, probably not the cleanest code.
Many thanks for the example. I'll try copy it if I get to this. I'm due for some actual code changes here. Thanks for adding typing as you add new features + fix bugs.
Goal 1: Try get mypy running on minimum typed code and iteratively work from there.
I added basic mypy checking in #482. I converted all the BNNN.abcd assignments to separate globals and annotated a bunch of instance attributes; otherwise it was mostly smooth sailing.
I added a few more types in #483. Here's a few next steps to take:
--check-untyped-defs
etc.)I might do a few of those things at some point but no guarantees. Others should feel free to put up incremental PRs too.
We should add type hinting everywhere across the code.
Happy for gradual, but eventually working up to mypy strict typing.