-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
TST: Add failing test #26522
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
TST: Add failing test #26522
Conversation
I guess the easiest is just to revert that change for Will add a PR tomorrow. |
Reverting that change leads to:
The line with the new error goes back to 3.3. Based on the doc-string, only Bbox and None are supported. That only Bbox is supported goes about ten years back. When did this work most recently? Is it possible that the added test is not similar enough to your use case? |
It "works" on the latest release version, the error only popped up in our https://github.com/mne-tools/mne-python/actions/runs/5858016804/job/15881180313#step:17:5090 I put "works" in scare quotes because if I revert to matplotlib 3.7 locally and check the type it's
It looks like that in 3.7 the clip_box we pass never actually gets used, because it gets overwritten by Print statements
So in other words, But a follow-up question arises: passing Using tuple on main
No idea if this is doing the right thing or not (my head is spinning trying to interpret the flow)... But it seems like you should get a TypeError that the |
Yes, the type checking is typically quite limited in most Will try to understand the rest of the very nice testing you provided and see if there is something else hiding here. The overwriting from |
ndarray errors because numpy dissallows The tuple has no such protections, and thus evaluates as False, which is not an error condition, but it remains not the correct type to be used as a BBox Now, bboxes do implement Unfortunately the relationships of these arguments which stem from Ultimately I will admit to a level of skepticism of the idea which appears to be at the center of wanting the clip box in the first place, which seems from my cursory glance at the code to be centered around using one Matplotlib.Axes object to serve as multiple logical axes by manually applying scaling factors and clip boxes. This is, in fact, the primary goal of Matplotlib Axes and the Transform stack. There are quite possibly some performance improvements to Matplotlib which alleviate (if not eliminate) the problems which caused that to be written in the first place. (Mind you, I have not run benchmarks, so I do not have anything empirical to back up the feeling that that is likely not as big of a gain as you would hope/intend, or potentially it once was) And further skepticism that it will continue to behave as expected for any interactive usage, or for resizing of the canvas (if all you do are static plots, that is certainly not a dealbreaker, just have a sense that it likely would behave strangely). If the performance gains are still relevant, what you probably want is instead of |
At the time we wrote the core of the code multiple Axes were indeed way slower, but it was also a long time ago. Certainly we could/should revisit better ways of doing what we want. And the |
As I think we've determined that this is okay to error, just that the error message could perhaps be better/sooner, I'm going to go ahead and close this as not a release blocker. |
This is a bug-report-as-PR -- MNE-Python
main
just started failing with:So passing
bbox-like
used to work but now doesn't (i.e., the test added here should fail). cc @oscargus as this seems to have been introduced by #26326Not sure if the correct solution here is to cast to
BboxBase
if not an instance of one or something... but at least in MNE-Python we can work around for now by passingtuple(bbox)
or so, so no rush from our end. 🤷