Enable and fix mypy

[mpharrigan]

We largely have type annotations throughout the code and I always keep an eye on the pycharm type-checker. However, we should enable mypy as part of the continuous integration (CI) checks. There are currently a lot of mypy warnings.

[tanujkhattar]

xref https://github.com/quantumlib/Qualtran/issues/259

[mpharrigan]

There's tonnes of noise and very little signal in mypy runs. I would wager that 90+% of the errors are (from most prominent to least)

• signature override thing, xref #131
• using NDArray[a_non_numpy_type]. We use numpy arrays around python objects, which is a completely legit thing to do. Ideally: the annotations on function arguments would be ArrayLike but this non-generic annotation was deemed to be less helpful to the user than NDArray[Thing] even though we also accept lists, etc. Anyways: mypy treats NDArray[Thing] to be an error unto itself
• re-using variable names for a new type
• type import errors from mypy aggressively trying to typecheck the entire python ecosystem.

---

the tooling should help the developer, not the other way around. To integrate mypy as a required check we need to figure out how to reduce some of this noise without burdening the develoepr

[mpharrigan]

xref https://github.com/quantumlib/Qualtran/issues/259

Right; I'm splitting this out to track separately

[fdmalone]

bloq_counts mypy errors too: See for example and_bloq.py: Return type "Set[Tuple[int, Bloq]]" of "bloq_counts" incompatible with return type "Set[Tuple[Union[int, Expr], Bloq]]" in supertype "Bloq" [override]

[mpharrigan]

why isn't that allowed? I thought overrides were allowed to have more specific types

[dstrain115]

mypy is now enabled as of #926