Rename mosaic layout #20150
Rename mosaic layout #20150
Conversation
This gives us the option to in the future combine *tight_layout* and *constrained_layout* into a single *layout* kwarg.
66e51af to
5d25e1f
Compare
|
I'm unclear if we should introduce or pre-announce this in 3.4.2. The faster we make the change the better. Similarly, we may still consider pushing for |
|
I am 👍 on backporting this for 3.4.2, contrary to my normally conservative position on these sorts of things. My reasoning is that given that we labeled this as provisional, then we should have the courage of our convictions and treat it as provisional! Setting that precedent is probably a good thing and this seems like a low-stakes case to try that in. I did consider leaving the variable as mosaic as the variable the tutorial, but went with changing it everywhere. Would going with variables like be better? I agree we should show of the short hand, I'll add that section once we agree on the variable names. I would also propose that with this name change we make mosaic non-provisional for 3.5, but I'll do that after this is in. |
Um, no. That's rather cryptic and it's not a pattern that scales. FWIW the single-line pattern should be inlined most of the time: What about alternative names:
|
|
My 2 cents, I thought "mosaic" was fine. IIRC, the context of that name was
to have something similar to "patchwork" so people might think it is
related.
…On Wed, May 5, 2021 at 4:55 PM Tim Hoffmann ***@***.***> wrote:
Would going with variables like
AABC = "AA;BC"
be better?
Um, no. That's rather cryptic and it's not a pattern that scales. FWIW the
single-line pattern should be inlined most of the time:
subplot_mosaic('AA;BC').
What about alternative names:
- arrangement
- formation
- structure
- placement
- zones
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#20150 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACHF6AB4LWUDP3CB7CF263TMGWF5ANCNFSM44B3LBZQ>
.
|
|
@WeatherGod not sure you got the context right. The function name will stay. It's only the name of the first argument. Up to now: Future: |
|
fwiw I think using |
|
Not sure if this should be backported to 3.4.2? |
|
oh, we should have talked about this on the call! |
|
I'd backport it? |
|
+1 for backporting |
|
@meeseeksdev backport to v3.4.x This will need a bit of extra work from @QuLogic to merge the api change note in. |
|
Owee, I'm MrMeeseeks, Look at me. There seem to be a conflict, please backport manually. Here are approximate instructions:
And apply the correct labels and milestones. Congratulation you did some good work ! Hopefully your backport PR will be tested by the continuous integration and merged soon! If these instruction are inaccurate, feel free to suggest an improvement. |
Merge pull request matplotlib#20150 from tacaswell/rename_mosaic_layout Rename mosaic layout
|
sigh, doing the manual backport. |
Merge pull request matplotlib#20150 from tacaswell/rename_mosaic_layout Rename mosaic layout
Merge pull request matplotlib#20150 from tacaswell/rename_mosaic_layout Rename mosaic layout
…-v3.4.x Backport PR #20150 on branch v3.4.x
PR Summary
This gives us the option to in the future combine tight_layout and constrained_layout into a single layout kwarg.
Even though this is provisional so I do not think we need to do a deprecation cycle, we may want to hold adding the layout kwarg until 3.6?
I took this opportunity to update the tutorial to use
fig.subfigures()as well!PR Checklist
pytestpasses).flake8on changed files to check).flake8-docstringsand runflake8 --docstring-convention=all).doc/users/next_whats_new/(follow instructions in README.rst there).doc/api/next_api_changes/(follow instructions in README.rst there).