Is this meant to be used bytight_layout, such that one could callfig.tight_layout(bbox_extra_artists=[])?

I think thats possible, though this PR doesn't do that. Not quite sure what happens if you specify an artist that isn't in the axes (tight layout would have to accept all the artists for each axes).

See update above: rebased and addedartist.inbbox to determine if an artist is in a bbox calculation or not.

I am happy with this in principle, but we probably need to add theget_* andset_* methods to keep the API guessable.

We need a better name thaninbbox as bbox is a bit arcane andinbbox reads to be as a question not an instruction.

added setters and getters, and changed name toartist.set/get_in_layout and madeartist._in_layout private.

@efiring Thanks for the review. Outstanding questions for others:

1. should this be aartist.set/get_in_layout or should it just be a property (artist.in_layout)?
2. Am I referring to the co-oridnate system of the bounding boxes correctly?get_tightbbox returns bounding boxes in pixels relative to the 0, 0 as the bottom left of the figure viewport. I'm referring to this as:

bbox : `.BboxBase`            containing the bounding box (in figure pixel co-ordinates).

I don't think this was ever properly specified before this PR. Probably becauseget_tightbbox andget_window_extents verge on private methods.

re 1. From the pythonic point of view this would just be an attributeartist.in_layout. A property does not make sense here. Properties are basically there to attach code to reading or writing an attribute without changing the signature. You can just use the attribute and turn it into a property later if needed.

The only argument for set/get would be that it's widely used within matplotlib. However there are also a few counter-examplesartist.axes,artist.stale.

It's up to one of the more senior devs to decide which way to go. Personally, I'd have a slight preference for the attribute solution.

From the pythonic point of view this would just be an attribute artist.in_layout.

Sorry, meant "attribute".

OTOH I think the issue is documentation - how does the user discover this attribute in the docs?

An attribute can have a docstring, and sphinx can include the documentation either by listing the attribute along with other explicit members, or via the autoattribute directive:

http://www.sphinx-doc.org/en/stable/ext/autodoc.html

I think@tacaswell really doesn't want to start doing this (using bare attributes) until the massive traitification is done, however. But maybe he will change his mind for cases like this.

I’d be all for either form, with slight preference for the attribute.@tacaswell?

I accept@tacaswell's argument that keeping the machinery provided by the setters and getters is worthwhile for this, so ignore my suggestion to reduce it to a bare attribute.

self merging as reviewed and passed CI

Grrrrr. This has a funny interaction w/ zooming. If I zoom, then the clip path of an artist is not set properly until after a draw. But all the automatic layout depends on being able to get a sensible tighbbox during draw... Darn race conditions....

I just spent several hours tracking down why my annotations were getting placed incorrectly after updating from Matplotlib v2.2.3 to Matplotlib v3.3.1. The problem turned out to beax.get_tightbbox() was not returning the same result as it did under Matplotlib v2.2.3. I am, however, pleased that I can get the old behavior withax.get_tightbbox(bbox_extra_artists=[]). Thanks for keeping some degree of backwards compatibility.

You can also twiddle manually:artist.set_in_layout(False)...