Should we do something about this?

I know it's ugly, but adding the get_{property} methods as aliases would preserve consistency.

I agree w/ @jklymak that property versions like ax.xlabel would be nice #26629 (comment) and that's something folks have been asking for for ages, that instead of {get,set}_property, they could behave like python properties - but that's also a project and a half.

@jklymak proposed set-less functions ax.xlabel(name), not properties ax.xlabel = name. Properties would be much more difficult because we often have optional parameters. I can see the argument for xlabel(). Semantically, this is more a declarative style compared to the imperative set_*. We'd also move logic closer to pyplot so that for setters they are equivalent plt.xlabel(name) / ax.xlabel(name). This could be nice, because we already have this parallelism for the functions adding data (like plot()). OTOH, we'd have to decide on getters. I don't think we want the MATLABism of pyplot "calling a function without arguements returns the current value". IMHO we still have to stick with getters. But that's ok; they are much less used.

That said, this would be a major API overhaul, and we'd have yet another way. While it's reasonable on its own. We should carefully decide wether we want that additional API surface, whether we want to afford this change knowing that there is more to come e.g. mpl-gui, and if we are touching on the API whether other patterns like e.g. method chaining (plot(x, y).xlabel('the x').ylabel('the y') are an option.

@jklymak proposed set-less functions ax.xlabel(name), not properties ax.xlabel = name.

Yeah, I should have said property-like b/c I was thinking of the pyplot pattern where the function is both the getter and setter. Which yeah, we'd want for consistency between the two APIs.