-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
[Bug]: colorbar with unattached mappables can't steal space #23709
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
Comments
Not directly related to #23502, but it may be that the logic for stealing and returning space should be discussed jointly. |
Do we know when we changed to following the mappable's axes? That seems like we made a mistake there, and this may be a release critical bug fix. Marking as such to make sure it gets discussed. |
It was discussed at #12333 (comment) (see in particular @tacaswell's comment just below) and deprecated in #12443. I still think the change is correct, we just need a better error message here. We could make |
I think that issue refers to the problem of what axes to steal from whereas this one refers to which axes to give back to. We can't assume the logic is reversible because we have a cax arguement and an ax argument to colorbar. |
I'm not sure I follow? Isn't this issue still about who to steal from? |
I'm sorry - I got confused by the reference to the other issue I think I'm ok with expecting the user to provide an axes if they just make an axes-less mappable and and expect plt.colorbar to do something. We could fall back to the current axes but in this case I think that would create an empty axes, which seems wrong as well. If they are creating their own mappable they have some savvy of our internals and can supply a cax argument. |
I agree this seems wrong, but I think stealing from the current axes (as problematic as that is) even if we have to create it is better than failing. I could go either way on warning (and raising in the future) in the case of an "orphaned" mappable without an explicit axes passed or not. |
I'm OK with going through a warning before completely killing this |
I disagree. I think failing is better and the user can tell us what they want explicitly if we can't infer it. |
Discussed on the call, I have been convinced we should give a better error as this was previously warned. |
Bug summary
This is something I noticed downstream in networkx: networkx/networkx#5937 (comment)
Formerly, space for a
Colorbar
was stolen from the currentAxes
; that was deprecated and now in 3.6, it is stolen from the mappable'sAxes
. But if the mappable is not added to anAxes
, it fails with a somewhat unrelated-looking error.Code for reproduction
Actual outcome
Expected outcome
Either we should switch to the current Axes if the mappable doesn't have one (probably not desired given the previous change), or raise a clearer error message when this happens.
Additional information
No response
Operating system
No response
Matplotlib Version
3.6.0rc1
Matplotlib Backend
No response
Python version
No response
Jupyter version
No response
Installation
pip
The text was updated successfully, but these errors were encountered: