Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork7.9k
Add explicit float type hint to attribute zoom#27958
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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 uson gitter for real-time discussion.
For details on testing, writing docs, and our review process, please seethe developer guide
We strive to be a welcoming and open project. Please follow ourCode 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
| defset_box_aspect(self,aspect,*,zoom:float=1): | |
| defset_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 youwill 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
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.
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.