I would rather push this to 3.0 (hoping to tag 2.2RC1 this weekend....only a week late)

I haven't looked in detail, but I will be glad to see this go in whenever it does, and the duplication go away.

Updated deprecation messages to say 3.0 instead of 2.2.

Rebased due to conflicts. These files are messy, so it would be nice to get this in quicker to reduce conflicts.

@anntzer or@dopplershift, perhaps one of you could have a look and merge this if it looks OK, so it doesn't have to be rebased again.

I'm not even close to knowing enough about axes_locator to decide whether the functionality is indeed duplicated or not.

Mainly you can look at theLocatableAxesBase class which adds[gs]et_axes_locator and then modifiesapply_aspect to use it before drawing. But looking at the regular_AxesBase.draw, itdoes the same thing.

LocatableAxesBase dates all the way back to8e3b931, Dec. 9, 2008, when all of the AxesGrid family was started. That original commit (which looks like a combination of SVN commits?) includes the duplication ofget_axes_locator, etc., and its use indraw prior toapply_aspect, inAxes and inLocatableAxesBase. It looks to me like originally it was in the latter, and then@leejjoon decided to add it toAxes but didn't remove it fromLocatableAxesBase. The_axes_locator is used only in connection with the AxesGrid family, as far as I can see; there are references to it in tight_layout and bbox_inches=tight, but only the AxesGrid family actually sets it.

It looks to me like we need to either support_axes_locator more thoroughly inAxes (which at the moment means taking care to keep it synchronized in the twin case, requiring a modification of the setter as well as of_make_twin_axes), or strip it out ofAxes and leave the locatable axes class, factory function, etc. in place, possibly with some changes.

I'm not sure which would be best; it's a little odd to have an attribute inAxes that is used only by a toolkit, isn't it? On the other hand, the cost is fairly low.

There are times when@leejjoonrecommended usingaxes_locator and not the full toolkit, so I think the intention was to put it into the base library, but I can't say that 100%. I can also find arandom use in the wild, but it's hard to search when a bunch of people commit their venvs to git.

Ooh, this fell through the cracks. Any chance we can resurrect?

I can rebase; depends on@efiring's thoughts.

My opinion is highly biased as I am the one who introduced the axes_locator. But I would like to see it stays. While I understand this is underused, this makes certain things a lot easier (although may not relevant for normal users). Also,#11026 requires axes_locator.

This doesn't remove it though; it deprecates the one in axes_grid for the one in the main library, which appears to be what#11026 uses.

Yes. I was just expressing my opinion to what@efiring said, and I was referring to axes_locator in the base. I am happy with the axes_grid becoming deprecated.

I'm more than a little confused--I haven't looked at this for a while, it deals with functionality I am not familiar with, and so the spinup in trying to come back to it is considerable.@leejjoon, it's good to hear from you--but could you be more explicit with respect to this PR? Do you favor it as is (after a rebase), or with minor changes, or major changes, or not at all?

I am in favor of this PR. In fact, I think we can actually removeaxes_grid toolkit from the code base.
On the other hand, I would prefer_axes_locator stays withinAxes. Let me know if I am still not clear.

@leejjoon, thanks very much, that's what I thought.@QuLogic, let's try to get this in now. Once it is rebased and passes the tests, anyone is welcome to merge it.

OK, rebase is done.