-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Enh/extend mosaic kwargs #24604
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
Enh/extend mosaic kwargs #24604
Conversation
I would use it, and I’d be excited to read about it in the what’s new. For a name, maybe something like |
I'm concerned about having two keyword arguments that are circular references to each other. What I mean is the docs are something like:
My concern is that coupled parameters leads to confusion about which parameter to use and what is prioritized; for example, confusion around colors. If consensus is that keeping these parameters separate is a good idea for the default fall through, then I think they should at least follow each other in the documentation and not be separated by the gridspec_kw. |
|
I like |
As mentioned in #24571, when there's no conflict any arguments passed to 'subplot_kw' are applied (line 2063-2064), which is why I'm calling that the default/(edit is probably more appropriate to say that subplot_kw is the fallback). But more to my point, the dev calling this function has to keep track of what they passed to both parameters when either one seems to be behaving strangely. |
6ca4fbb
to
c058015
Compare
per the call:
|
a724652
to
562ba8d
Compare
lib/matplotlib/figure.py
Outdated
@@ -1821,6 +1841,9 @@ def subplot_mosaic(self, mosaic, *, sharex=False, sharey=False, | |||
The string notation allows only single character Axes labels and | |||
does not support nesting but is very terse. | |||
|
|||
Tuples may be used instead of lists and tuples may not be used |
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.
Tuples may be used instead of lists
Do we want to allow this explicitly? I'm in favor of having one documented and recommended way, so that usages are consistent and not half of the people are using lists and the other half tuples.
It's a separate topic that tuples are accepted due to duck-typing and can be used in special situations.
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.
Agree to drop the first half of this sentence as many things will "work":
import matplotlib.pyplot as plt
from collections import deque
a = deque([deque(['A', 'B']), deque(['C', 'D'])])
plt.subplot_mosaic(a)
plt.show()
but we should only document one spelling. In the tutorial I think we also pass a 2D numpy array.
Maybe the input should be "something coercible to a numpy object array of hashables"?
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.
This also "works" 🤦🏻
plt.subplot_mosaic(frozenset([frozenset('ab'), frozenset('cd')]))
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 updated this wording.
On one hand, no one has complained that they can not use tuples as keys yet, on the other hand if we take "tuple is broadcast" in this PR then relaxing this in the future would cost of some tricky logic around sorting out what to do about:
plt.subplot_mosaic([[('a', 'b'), 'a'], ['b', 'c']], per_subplot_kw={('a', 'b'): {}})
I think you have to always treat the tuple as "can I broadcast this" first and then we decide if we fallback to "maybe this is a key?" (as if you do it the other way you can never broadcast to 'a' and 'b' in this case). We might also be able to break this ambiguity by requiring tuple keys to always be nested in another tuple for per_subplot_kw
as {(('a', 'b'),): {}}
which is annoying, but not the worst.
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 the wording as you have written it now is the correct solution:
The Axes identifiers may be
str
or a non-iterable hashable object (e.g.tuple
s may not be used).
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 have some tiny doc suggestions. Also should the new keyword be included in the pyplot.subplot_mosaic
docstring?
Otherwise, this looks good to me.
@rcomer pyplot should be updated, thank you for catching that! |
Drat, I have been seeing those docs build failures locally for a while now and had not chased them down the source of the problem. Given that numpy 1.24 just came out I am now confident that it was a change to numpy, looking into this.... |
ok, I understand the doc failure and will open a separate PR to fix it. |
This is already done at creation time.
Co-authored-by: Tim Hoffmann <[email protected]>
Co-authored-by: Ruth Comer <[email protected]>
68d53c3
to
5b0fb4a
Compare
Co-authored-by: Elliott Sales de Andrade <[email protected]>
aa3cda5
to
e56f876
Compare
PR Summary
Closes #24571
Open questions:
PR Checklist
Documentation and Tests
pytest
passes)Release Notes
.. versionadded::
directive in the docstring and documented indoc/users/next_whats_new/
.. versionchanged::
directive in the docstring and documented indoc/api/next_api_changes/
next_whats_new/README.rst
ornext_api_changes/README.rst