I'm not really happy with the two-letter compass notation. It's not readable. loc='SE' is obscure while loc='lower right' is self-explanatory.

For me, the only reason to introduce this is that we already have that in other parts of the library.

For information, MATLAB uses written-out compass notation:
https://de.mathworks.com/help/matlab/ref/legend.html#bt6ef_q-1-lcn
In itself, that's not too bad. However, I doubt we should not introduce yet another format. Also MATLAB has "*outside" locations, which would be really nice, but that's another topic.

The main advantage is that it is completely unambiguous and hence straight forward to remember. It seems there are a lot of people who need to google for the correct names/codes each time they do a plot, so this is guaranteed to be helpful for those in need of it (others don't have to care).

Concerning readability, note that I am explicitely not proposing to change the examples to use this compass notation.

I'm fine with this proposed notation, particularly as we use it elsewhere. "left centre" is really bad. I'd be fine with "west" as well as "W".

I think I have a mild preference for the MATLAB-style(!!) spelled-out strings "northeast" etc (as long as we use it everywhere). Let's say +0.5 for "northeast" and +0 for "NE" (but only one of them, and has to be consistent with eg. inset locator).

I'm afraid we cannot easily get around the short "NE". It's already been used e.g. for anchors https://matplotlib.org/api/_as_gen/matplotlib.axes.Axes.set_anchor.html. Even if we decide to use "northeast" everywhere, we'd have to keep "NE" around for the anchor (at least for a deprecation period, but I tend to not deprecating that).

Should I allow for "northeast" in addition to "NE" then?

(Note to self: This still needs a what's new entry.)

Should I allow for "northeast" in addition to "NE" then?

I'm +/-0 on this. It's a more readable convention. OTOH, it's not good to have too many ways to specify things.

Should I allow for "northeast" in addition to "NE" then?

I don't think it makes sense to add more than one way to do it for legends. Pick an "ideal" name to use for legends, and then update anchors to support that new ideal name, optionally deprecating the old one.

I don't think it makes sense to add more than one way to do it for legends. Pick an "ideal" name to use for legends, and then update anchors to support that new ideal name, optionally deprecating the old one.

That's the conflict here. IMO "southeast" is to be preferred to "SE". But "SE" is already used for anchors (https://matplotlib.org/api/_as_gen/matplotlib.axes.Axes.set_anchor.html). Different terminologies for legends and anchors make no sense. That would mean "SE" would need to be depreacated for anchors. But OTOH is it worth it?

I wouldn't overly worry about set_anchor, which is likely much more rarely used than legend() (and already not consistent). If we switch to spelled-out compass directions, I'd just do the deprecation dance on set_anchor.

👍 in general, I am -0 on supporting both the abbreviations and the full names, and +1 on no spaces if we do full names. I am not sure which way to go on full names vs abbreviations though.

xref #13072

in general, I am -0 on supporting both the abbreviations and the full names, and +1 on no spaces if we do full names. I am not sure which way to go on full names vs abbreviations though.

I am still 👍 , but on the phone call @efiring convinced me that we should do both and with spaces is going to be easier to read.

Strong preference for spaceless longforms.

Following up, on the call again,

• allow short notation (no spaces) all uppercase
• allow long notation (no spaces) all lowercase

Updated.
This now introduces "NW" as well as "northwest" as locations for the legend, as well as for other anchored artists and inset_axes.
For this I externalized the mapping from the possible input values into cbook, such that it can be reused everywhere. Internally, the one- or two character strings are now used to specify the location. (Previously strings got mapped to numbers, than back to those compass location codes.)
This should preserve all deprecations, although there is an attribute self._loc_used_default which got lost when rebasing - and I have absolutely no idea about its purpose and I still need get this pass the tests.

I introduced getters and setters for loc as well. This is a new feature, which allows to set the location a posteriori, and it also ensures that if people used the private attribute self._loc in their code to achieve the same, their code would not fail through this change.

flake8:

./lib/matplotlib/cbook/__init__.py:2170:1: W293 blank line contains whitespace
./lib/matplotlib/cbook/__init__.py:2192:1: W293 blank line contains whitespace
./lib/matplotlib/cbook/__init__.py:2198:1: W293 blank line contains whitespace

Labelled "work in progress" due to the unclear state of backward incompatibility.

#12679 (comment)

The problem with backwards incompatibility is the following:

This PR attempts to simplify the positionning code, such that internally, the short compass notation is used throughout. Previously we would convert from strings to numbers ("lower left" --> 3), then from numbers to compass (3 --> "SW"). With this PR the intermediate step is removed. This works nicely for legend, because there is no public method for getting or setting the location.
Now to the problem: AnchoredOffsetbox does have a public loc attribute. It's easy to route any assignment to this though the new converter. However, reading out this attribute would yield a different value, i.e. "SW" instead of 3. This is an API change.

The cleanest solution to this would be to

• start a deprecation, like "Warning, this attribute will return the location in compass notation in the future"; but then the question is how to allow people to adapt their code already now? Usually I would go on with "To prevent this warning and use the compass notation already now, use the get_loc method instead." However, some concerns were raised about adding such get_loc method. But without such new method, no useful deprecation can be performed.

Alternatives are of course:

• Ignore the fact that this is an API change; presumably the number of cases where someone want to read out AnchoredOffsetbox.loc is quite small.
• Reintroduce the conversion from string to number, i.e. let loc work with the numbers, only convert to short compass notation at the very end. This would render some of the attempted simplifications of this PR useless.

One solution for strict backcompat (frankly, I think the change would affect vanishingly few people) could be to make the compass locations IntEnums (instead of strs), which subclass int so they behave like ints for all purposes (see the similar thing I did for MouseButton).

Alternatively, control whether AnchoredOffsetbox.loc is a number or a string using a global rcparam (ugh), emitting a deprecation warning when loc is accessed if the rcparam value is "legacy" (or however we want to call it).

I don't think I understand the IntEnum proposal. Would that mean to have some LocClass.NW object people need to use instead of "NW" or "northwest". Wouldn't that

(a) result in the same problem of making a decision on the "standard" kind of location, i.e. between LocClass.NW and LocClass.northwest?
(b) Introduce a hysteresis in arguments you pass (i.e. a string "northwest") versus arguments you get out (i.e. a number/enum LocClass.NW)? Or should users then pass LocClass.NW themselves?

Users would remain able to pass in "NW" or "northwest" (or Location.NW, or 2), but when reading out the loc attribute they would get Location.NW. Because Location.NW would be an IntEnum, it would compare equal (for == or as a dict key or whatnot) to its current int value (2).
Essentially, Location.NW is the number 2, just with a nicer repr.

Pushing to 3.3, but have not read through the full discussion. If people think this has converged and can be merged in the next ~3 days please do so for 3.2.

This is correctly labelled "Work-in-progress" and cannot be merged as is. It will need new input from my side followed by a new round of dicussion.

Here's a suggestion including outside axes with compass notation, essentially treating each cell as a coordinate point from the center. Two steps in any direction is outside the axes. (Admittedly, northnorth might sound awkward.)

   │NNW│ NN│NNE│
───╆━━━┿━━━┿━━━╅───
WNW┃NW │ N │ NE┃ENE
───╂───┼───┼───╂───
 WW┃W  │ C │  E┃EE
───╂───┼───┼───╂───
WSW┃SW │ S │ SE┃ESE
───╄━━━┿━━━┿━━━╃───
   │SSW│ SS│SSE│

Since this Pull Request has not been updated in 60 days, it has been marked "inactive." This does not mean that it will be closed, though it may be moved to a "Draft" state. This helps maintainers prioritize their reviewing efforts. You can pick the PR back up anytime - please ping us if you need a review or guidance to move the PR forward! If you do not plan on continuing the work, please let us know so that we can either find someone to take the PR over, or close it.