-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Make pyplot more tolerant wrt. 3rd-party subclasses. #12293
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
0755ea7
to
7ddf5fd
Compare
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.
The fact that all this didn't trip any test changes means to me that we aren't testing the signatures completely, and that is making breaking changes opaque to us, but a problem for downstream packages. If we decide to change the signatures, that should fail some tests, which can then consciously be removed if need be, and accompanied by the appropriate API change notes. (i.e. the changes made in #10918 shoudl have failed some tests so we knew we were causing problems, so this is the time to add those tests)
It's going to be pretty tricky to test this unless we make a copy of all pyplot signatures somewhere else to compare against, which sounds not so nice. |
I don’t think they all have to be tested just a smattering to make sure the boilerplate is doing the right thing. I do t understand what you mean by copying all the pyot signatures but maybe I’m misunderstanding what is going on here |
It's not clear to me what test you exactly want to add either... |
Ideally there would be some tests that would have failed #10918, which presumably means duplicating whatever signature cartopy was trying to use. But again if there is a more informed critical mass of devs who don't think this is possible they should feel free to dismiss my review. I'm not claiming deep understanding |
I have not gone through the changes, but this is sufficient to get Cartopy tests working again. Keep in mind that Cartopy does not of course exercise the entirety of the
|
TBH I am not particularly interested in figuring out how to do implement a test (especially wrt what guarantees we want to make regarding the subclassability of Axes). |
I think all I'm asking for are tests that test the allowed signatures, which I think is where the downstream subclasses are tripping up. But again, anyone who understands this better can dismiss my review if I'm off base about the testability of this. |
Can you open the request for tests as a separate issue instead? |
I still think we should test these code paths so we don't break things like this in the future.
Don't force them to reproduce the names of "intended-as-positional" arguments; don't force them to support the data kwarg. This is also necessary for methods that take `*args`, as otherwise we generate a call of the form `foo=foo, *args` which is incorrectly understood as `*args, foo=foo`.
7ddf5fd
to
7809b91
Compare
Clarified in the commit message why this also closes #12405. |
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 think it's reasonable to request at least one small smoke test be added to this PR to check that all is working. The short example in #12405 should be enough
Can you push it? |
Done! |
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.
Works for Cartopy.
pyplot signatures need more tests |
…293-on-v3.0.x Backport PR #12293 on branch v3.0.x (Make pyplot more tolerant wrt. 3rd-party subclasses.)
Don't force them to reproduce the names of "intended-as-positional"
arguments; don't force them to support the data kwarg.
xref #12288
attn @QuLogic can you pick it up from there if more changes are needed?
PR Summary
PR Checklist