In how far is it bearable or confusing for users to have

• anaxes_grid1.inset_locator.inset_axes which creates aaxes_grid1.parasite_axes.AxesHostAxes
• anaxes.Axes.inset_axes which creates a.axes.Axes ?

(I could imagine the problem arising because people are used to have the same function at different places, e.g.plt.plot vs.axes.Axes.plot)

mplot3d call toplot objects return a different object than coreplot. I don't personally think it should be a problem...

I am done w/ this for now, and it can be reviewed if anyone has any suggestions. (note looks like a spare debug change got into the PR, but I'll remove after/during review).

What I definitely like better about theaxes_grid1.inset_locator.inset_axes is that you get some automatic padding, similar to a legend.
Here, any padding is either in percent of the parent axes width/height (i.e. the position would shift if the axes size changes) or you need to create an offset transform from scratch to supply to thetransform argument.
So the equivalent of

from mpl_toolkits.axes_grid1.inset_locator import inset_axesaxins = inset_axes(ax, width="40%", height="30%")

would be

from matplotlib.transforms import ScaledTranslationoffset = ScaledTranslation(-5/72., -5/72., fig.dpi_scale_trans)trans = ax.transAxes + offsetax.inset_axes([.6,.7,.4,.3], transform=trans)

which is a bit cumbersome to write for such standard case.

If that's a desirable feature (not certain yet, but possibly), certainly it should be pulled to core so that legend, text annotations and whatnot can also benefit from it?

@anntzer I think in its current formaxes_grid1.inset_locator.inset_axes should not simply be pulled over, because it has some design flaws which become apparent once you leave the standard use case.
You may read#11060 and links therein to see what is confusing about it (and also review if you like ;)).

So for the core matplotlib, one should probably spend some more thoughts about how to best design such function to be powerful, but not as confusing.

@anntzer and@ImportanceOfBeingErnest, thanks for the feedback. I think the logic for padded boxes is indeed in.offsets.AnchoredOffsetBox.

.offsets.AnchoredOffsetBox works from the idea that you want to put the box somewhere semi-automatically inside an axes (or other bbox). In that case a padding makes some sense. But I find the whole API hard to deal with if I just want to put a box (or axes) somewhere deterministic on the figure or parent_axes. So here, I was trying to be more deterministic with a more streamlined API.

What might make sense is to add a "pad" parameter in appropriate units (probably points, versus pixels), that would offset the new inset axes from the rectangle provided. Then if you want upper right you do:

w=0.2,h=0.2axins=ax.inset_axes([1-w,1-h,w,h],pad=5)

I don't think thats hard to do, though I'll have to check how its done to be robust under figure size changes. Could have anhpad andwpad if desired. I'd tend to be against different pads left and right, up and down...

Not sure how all that would work with set aspect ratios for the child axes.

Would something like that satisfy the need?

Conversely, I'm not 100% against just moving theinset_axes into core. But I really don't like the API, so felt this would be a decent time to change it. I appreciate some power users have figured out how to make it work, and recent attempts to improve the documentation have been heroic, but...

EDIT: cross-post!

To be clear, I think this should go in without padding support, because it's basically using the same positioning syntax astext, which is a good thing. Padding support should get its own discussion (and I'm not even certain it's something worth the complexity).

I guess personally I don't have a problem with padding just being a fraction of the axes size (i.e. I can hard code it intorect), but I can see why it is nice to have in physical units for consistency between different sized-axes. But I'm more than happy to leave that for a future PR, either as a new method or by enhancing the API of these methods. I don't think there is anything architecturally that needs to change to make that work.

I'm thinking more in terms of ease of use. One can always argue that if people want to have full control they can reach their goal via the axes_grid1 inset or custom transforms etc.
So I'm comparing tolegend here, because that is similar in the sense that you have a box with some extra information in. You may calllegend() without any argument and get a nice legend. This has some padding to the outside and if you don't like the position you'd addloc=4 at most. Apart it's still deterministic and fully customizable, using all the remaining arguments.

In that sense, something like

def inset_axes(loc="upper right", pad=0.5, width=0.4, height=0.3, box=None, transform=None):

which can be called just asax.inset_axes() could be more desireable.

I think "loc=number" is aterrible API.At least that should be using strings (which are also allowed with legend, but I would want new APIs to only use strings).

ping@efiring and@timhoffm if the new name suits. We could discuss on Monday's dev call, except I'll be unavailable. Happy to chat it out on gitter as well...

Rebased and squashed. Be nice to get this in relatively soon because then I can move onto axes for secondary scales...

recycled for CI

rebased

This just needs one more review to go in as a pretty useful 3.0 feature. OTOH, understand if it needs to get pushed 6 months...

Rebased and renamed to plain oldinset_axes per@efiring.@timhoffm that may invalidate your approval? I'll leave it to the maintainers whether this has enough approval...