Skip to content

ENH: add ability to remove layout engine #22452

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

Merged
merged 2 commits into from
Aug 9, 2022

Conversation

tacaswell
Copy link
Member

PR Summary

This may be too simplistic as it just sets it to None which gives you ability
to "go through zero" and change to an incompatible layout engine.

PR Checklist

Tests and Styling

  • Has pytest style unit tests (and pytest passes).
  • Is Flake 8 compliant (install flake8-docstrings and run flake8 --docstring-convention=all).

Documentation

  • New features are documented, with examples if plot related.
  • [N/A] New features have an entry in doc/users/next_whats_new/ (follow instructions in README.rst there).
  • [N/A] API changes documented in doc/api/next_api_changes/ (follow instructions in README.rst there).
  • Documentation is sphinx and numpydoc compliant (the docs should build without error).

@tacaswell tacaswell added this to the v3.6.0 milestone Feb 11, 2022
@tacaswell tacaswell force-pushed the enh_null_layout_engine branch from b0c1c49 to cb0410a Compare February 11, 2022 20:22
Copy link
Member

@timhoffm timhoffm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ping @jklymak are there any traps when removing layouts?

@jklymak
Copy link
Member

jklymak commented Feb 13, 2022

I can't think of any. It just doesn't get run.

@tacaswell tacaswell force-pushed the enh_null_layout_engine branch 3 times, most recently from aa2a746 to dd7c2e0 Compare March 25, 2022 03:30
@tacaswell
Copy link
Member Author

I added a NullLayoutEngine despite @anntzer 's concerns because I was worried about

fig. set_layout_engine('tight')
fig.set_layout_engine('none')
fig.set_layout_engine('constrained')

as away of "going through 0" and doing something that we put a bunch of effort into preventing!

@tacaswell tacaswell force-pushed the enh_null_layout_engine branch from dd7c2e0 to 8640ceb Compare March 25, 2022 03:32
self._colorbar_gridspec = colorbar_gridspec
super().__init__(**kwargs)

def execute(self, fig):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess I'm not sure about adding a Null engine here. It makes set_layout_engine('none') go through a (slightly) different codepath than never setting the layout engine at all. If we do this, we should probably initialize the figure with this NullLayoutEngine? But I'm not sure why we want to have this at all.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can not stick a formatter on at init time without making the bools tri-states ({unset, True, False}). This acts as a no-op place holder that remember the colorbar related settings without inventing another side-band way to store that.

Unfortunately I think that "never been set" vs "was set and then removed" are in fact different.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I see - we don't want to switch colorbar behaviour after it has started to be used... So we are turning off the algorithm, but keeping its side effect.

At some point we need to figure out how to ditch the two ways of placing colorbars without breaking everybody.

@jklymak
Copy link
Member

jklymak commented May 18, 2022

Doc build error:

WARNING: error while formatting signature for matplotlib.layout_engine.NullLayoutEnigne: Handler <function mangle_signature at 0x7f20ea43a4c0> for event 'autodoc-process-signature' threw an exception (exception: Unknown section Parameter in the docstring of NullLayoutEnigne in /home/circleci/project/lib/matplotlib/layout_engine.py.)

@jklymak jklymak added topic: geometry manager LayoutEngine, Constrained layout, Tight layout status: needs review labels May 24, 2022
@jklymak
Copy link
Member

jklymak commented Jun 2, 2022

I'll move to draft until the doc error is fixed...

@jklymak jklymak marked this pull request as draft June 2, 2022 14:31
@tacaswell tacaswell marked this pull request as ready for review June 2, 2022 17:02
@@ -101,6 +101,28 @@ def execute(self, fig):
raise NotImplementedError


class NullLayoutEngine(LayoutEngine):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to have this public?

Can we think of a better name? Something that catches "mirror the behavior of whatever layout engine it is replacing"? Maybe FrozenLayoutEngine or LayoutEngineSnapshot? Also this behavior is the key reason for the existence of the class. It should be prominently in the docstring, not only in the parameter description.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This turns the layout engine off, so I don't think it really freeze the layout manager?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a difference between None and NullLayoutEngine, and we have to capture that at least in the docstring but if possible already in the class name. NullLayoutEngine sounds as if it does nothing at all and intuitively I'd have expected that that's equvalent with the initial state None.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NullLayoutEngineLockedColorbarImplimentation is a bit long!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BTW, I think this needs to be public because the user can get it as a result from get_layout_engine. Maybe what is needed is a sentence of explanation for the user in the docs....

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the other hand, NullLayoutEngineLockedColorbarImplimentation is not something we expect a user to ever directly create and it very clear about what is it and communicates to the user something funny is going on.

If we document this publicly then it will also be a very unique search term to land users at the right place in the docs.

"""
A no-op LayoutEngine.

This is primarily to act as a place holder if we remove a layout engine.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This is primarily to act as a place holder if we remove a layout engine.
This is acts as a place holder if we remove a layout engine. However, different layout engines
require different colorbar implementations and some are not compatible with ``subplots_adjust``,
so this Null engine retains the requirements of the last-used layout engine.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an improvement 👍 . Can you make it even more explicit: "different layout engines require different ..." / "some are not compatible". To my knowledge we have exactly two layout engines we are talking about.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, but the goal of this hook was to make it easy to add more / let external libraries provide their own so I think that leaving this general is the optimistic position.

@jklymak
Copy link
Member

jklymak commented Jun 23, 2022

... moved to draft pending rebase and rename (which I mean, fine, I don't care what the name is)

@tacaswell tacaswell force-pushed the enh_null_layout_engine branch from dcc9693 to 1ff8d49 Compare June 26, 2022 03:28
This also adds a "place holder" layout engine to ensure that users can not "go
through zero" and change to an incompatible layout engine.

Co-authored-by: Jody Klymak <jklymak@gmail.com>
@tacaswell tacaswell force-pushed the enh_null_layout_engine branch from 1ff8d49 to f7f3bb6 Compare June 26, 2022 03:30
@jklymak
Copy link
Member

jklymak commented Jun 30, 2022

Is this still draft @tacaswell ?

@tacaswell tacaswell marked this pull request as ready for review August 2, 2022 16:33
@tacaswell
Copy link
Member Author

@jklymak Are you happy with the documentation in this PR?

@jklymak
Copy link
Member

jklymak commented Aug 2, 2022

Still looks fine to me! Thanks,

- 'tight' uses `~.TightLayoutEngine`
- 'none' removes layout engine.

If `None`, the behavior is controlled by :rc:`figure.autolayout`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Were we doing *None*?

Copy link
Member Author

@tacaswell tacaswell Aug 4, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We seem to have about the same number of both

$ ack  '\*None\*' -l | wc
     56      56    1865
$ ack  '`None`' -l | wc
     61      61    2223

[edit updated to exclude docs build product]

Co-authored-by: Elliott Sales de Andrade <quantum.analyst@gmail.com>
@QuLogic QuLogic merged commit 357bac5 into matplotlib:main Aug 9, 2022
@tacaswell tacaswell deleted the enh_null_layout_engine branch August 9, 2022 13:27
@QuLogic QuLogic mentioned this pull request Sep 9, 2022
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: geometry manager LayoutEngine, Constrained layout, Tight layout
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants