Repository navigation
[Bug]: ax.xaxis.set_label(...) doesn't set the x-axis label #27971
Description
Bug summary
I'm used to using the Axis API like ax.xaxis.set_major_formatter(...) etc., so to be consistent it would be nice if one could do ax.xaxis.set_label(...) instead of ax.set_xlabel(...). It seems like ax.xaxis.set_label(...) does not label the axis however.
Code for reproduction
import matplotlib.pyplot as plt
fig, ax = plt.subplots()
ax.xaxis.set_label("x-label")Actual outcome
Expected outcome
Additional information
No response
Operating system
No response
Matplotlib Version
3.8.3
Matplotlib Backend
No response
Python version
No response
Jupyter version
No response
Installation
conda
Activity
ksunden commentedon Mar 24, 2024
The method you are looking for is
set_label_textset_label is the inherited method from Artist which provides the text that would appear in a legend entry (odd to do for Axis, but is defined by Artist)
However, confusingly, get_label is actually overridden with a different meaning in Axis, where it returns the Text instance of the label. (And so I might expect the setter to error with a raw string, but expect a Text instance)
I will state that the "_text" postfix is itself confusing, because it is given a string and is opposed to the version which uses Text.
dstansby commentedon Mar 24, 2024
Thanks - I thought something like that might be going on. Shall we close as won't fix then? Or we could keep open and as an action deprecate the overriden
get_text()in favour ofget_label_text()(if that would even be technically possible...)?timhoffm commentedon Mar 24, 2024
Please leave open. I will think about whether we can make this less confusing when I have a quiet minute.
timhoffm commentedon Mar 24, 2024
The name label is very broad and used for different things in different contexts. It would have been better to either be more specific
set/get_legend_labelor distinguish data and decoration Artist categories, which could have individual interpretations oflabel. But we are not in a place to change either. To limit misuse and confusion I propose to:set_label()inAxisandraise RuntimeError("A legend label cannot be assigned to an Axis"). While this explicitly breaks Liskov's Substitution Principle, that principle was already implicitly broken by the design, i.e. deriving Axis as a class that cannot have legend entries from the Artist class that assumes it can have legend labels. IMHO it's better to make this explicit and fail loudly instead of silently accepting a value and not ever doing anything with it.get_label(). We should not be overwriting this with different semantics than the base class. Instead, suggest to access the attributeAxis.labeldirectly. Whether that's a good pattern is a differerent topic. It's already there as an interface, so it won't go away too easily. Alternatively, one could addget_axislabel()(consistent with the existingAxis.get_ticklabels().When the deprecation expires, either fall back to the original behavior or, preferrably also raise a RuntimeError.
MNT: Prevent users from erroneously using legend label API on Axis
MNT: Prevent users from erroneously using legend label API on Axis
MNT: Prevent users from erroneously using legend label API on Axis
MNT: Prevent users from erroneously using legend label API on Axis
MNT: Prevent users from erroneously using legend label API on Axis
MNT: Prevent users from erroneously using legend label API on Axis
MNT: Prevent users from erroneously using legend label API on Axis
MNT: Prevent users from erroneously using legend label API on Axis (#…
MNT: Prevent users from erroneously using legend label API on Axis (m…