Add explicit float type hint to attribute zoom #27958
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Thank you for opening your first PR into Matplotlib!
If you have not heard from us in a week or so, please leave a new comment below and that should bring it to our attention. Most of our reviewers are volunteers and sometimes things fall through the cracks.
You can also join us on gitter for real-time discussion.
For details on testing, writing docs, and our review process, please see the developer guide
We strive to be a welcoming and open project. Please follow our Code of Conduct.
|
I'm quite hesitant to add a lone type hint in an otherwise untyped module. Especially doing so inline when the bulk of the library uses stub files. I'm sorry that pylance is inferring the wrong type, but we did not provide any type hints for 3D (or other I'd not be opposed to a bit larger scope of expanding type hints into 3D, and wouldn't even be too offput by doing less than complete hinting, but I think the granularity needs to be likely per file, not down to a single hint. I think my inclination is to do stubs here as well, though willing to be convinced to do inline (currently we only do inline in pyplot (which is partially generated code), tests (which are only minimal hints to appease checkers), and one or two private modules (mostly to lay foundation for perhaps inlining in the future, but probably not for at least one more release cycle, probably longer)) |
| @@ -345,7 +345,7 @@ def _equal_aspect_axis_indices(self, aspect): | |||
| ax_indices = [1, 2] | |||
| return ax_indices | |||
|
|
|||
| def set_box_aspect(self, aspect, *, zoom=1): | |||
| def set_box_aspect(self, aspect, *, zoom: float = 1): | |||
There was a problem hiding this comment.
| def set_box_aspect(self, aspect, *, zoom: float = 1): | |
| def set_box_aspect(self, aspect, *, zoom=1.0): |
This is a smaller change that should address the inferred type without broaching adding typehints in an unhinted module.
Again, if you are expecting type hints with 3D you will be continually disappointed at present, so caution is in order in general.
I'm still skeptical of the whack-a-mole here, but this would be my preferred short term solution to this particular typing error.
There was a problem hiding this comment.
I do agree that changing the type for a single line is a bit ridiculous, especially because the same Problem occurs at least a few dozen times in this file.
After looking at the file again there are only about 100 function, many without arguments, so wouldn't take too long to add typing to the entire file. So maybe I'll do that later.
QuLogic
changed the title
|
I moved this to draft because I agree we do not want to do one-off inline type hinting. We should either do a stub for the whole file or change the default to 1.0 to help down stream inferences. |
Fixing Issue [#27957] by adding a explicit type hint, to prevent assumed int type.