A number of the type hints on function/method parameters were incorrect (producing errors detected statically by mypy, or by temporarily instrumenting the code at runtime with typeguard). This fixes most of those.
A few names of attributes and function parameters were renamed in one place but not another. The affected function parameters, which were mostly on local helper functions, were unintentionally unused, while their old now-unbound names were still referenced. This went undetected because it was on code paths that weren't often exercised. This fixes most (maybe all) cases of that.
More minor changes (only made in code already being changed):
This adds a few more type hints in places where it is simple to do so and improves consistency, and in some places where type checkers like mypy consider it an error for them to be absent.
In some cases, the incorrect type annotations or incomplete renames appear to have arisen in part due to parameter names with non-obvious meanings, or that vary in meaning across code that otherwise appeared similar. In places where it looks like that was the case, this renames them accordingly.
To keep this PR reasonably scoped, it focuses mainly on fixing bugs. So:
I have deliberately not added type annotations to code that does not have them (except for code nearby and closely related, as summaried above).
I have not attempted to make the type hints as narrow as possible. Although I have sometimes turned an X into an Optional[X] (because PEP 484 prohibits implicit optional, and type checkers treat it as an error), and used the type Sequence[int] in a few places (formerly annotated with list, where range must also be accepted), this PR otherwise makes no use of type arguments (types that bind to a type variable in a generic type). Although I think such a change may be beneficial (for example, many functions could return types of the form Tuple[X, Y] instead of tuple), I regard it as both less important than the changes here and outside the reasonable scope of this pull request.
I have not attempted to fix every possible type error. Some mypy warnings that I believe were correct did not have clear fixes, and I didn't want the rest of these changes to be held back indefinitely. I have tried to make sure I was not introducing any new mypy warnings.
bazingagin
commented
1 year ago
Important changes:
A number of the type hints on function/method parameters were incorrect (producing errors detected statically by
mypy, or by temporarily instrumenting the code at runtime withtypeguard). This fixes most of those.A few names of attributes and function parameters were renamed in one place but not another. The affected function parameters, which were mostly on local helper functions, were unintentionally unused, while their old now-unbound names were still referenced. This went undetected because it was on code paths that weren't often exercised. This fixes most (maybe all) cases of that.
More minor changes (only made in code already being changed):
This adds a few more type hints in places where it is simple to do so and improves consistency, and in some places where type checkers like
mypyconsider it an error for them to be absent.In some cases, the incorrect type annotations or incomplete renames appear to have arisen in part due to parameter names with non-obvious meanings, or that vary in meaning across code that otherwise appeared similar. In places where it looks like that was the case, this renames them accordingly.
To keep this PR reasonably scoped, it focuses mainly on fixing bugs. So:
I have deliberately not added type annotations to code that does not have them (except for code nearby and closely related, as summaried above).
I have not attempted to make the type hints as narrow as possible. Although I have sometimes turned an
Xinto anOptional[X](because PEP 484 prohibits implicit optional, and type checkers treat it as an error), and used the typeSequence[int]in a few places (formerly annotated withlist, whererangemust also be accepted), this PR otherwise makes no use of type arguments (types that bind to a type variable in a generic type). Although I think such a change may be beneficial (for example, many functions could return types of the formTuple[X, Y]instead oftuple), I regard it as both less important than the changes here and outside the reasonable scope of this pull request.I have not attempted to fix every possible type error. Some
mypywarnings that I believe were correct did not have clear fixes, and I didn't want the rest of these changes to be held back indefinitely. I have tried to make sure I was not introducing any newmypywarnings.