This is technically a new feature and needs to be mentioned in the whatsnew.

Given that setting labels without positions is already possible with ax.set_xticklabels, I wouldn't worry about exposing it in pyplot as well.

Note that four your example, one should rather use plt.boxplot(labels, data).

I think there are still cases in which pure label setting is reasonable. Though, I'm slightly concerned that people might abuse this freedom and end up with labels at unexpected positions.

Indeed, my example was not good. I was checking my code that originated this suggestion and noticed that I set xticks through plt because I was plotting inside a for cycle. However, I could've just set the labels inside the for cycle using the arg positions. As for stacked bar graphs, one can use the tick_label arg.

So, it might be the case that there's no real use case for this change, except for possibly convenience.

I did some tests with bar graphs, and this addition can actually lead to unexpected results. Differently from boxplots, bar graphs don't always present one xtick per bar. Thus, setting the labels without locs can lead to unexpected (from the user point of view) positioned labels. Here's an example from https://matplotlib.org/3.1.1/gallery/lines_bars_and_markers/bar_stacked.html:

By changing plt.xticks(ind, ('G1', 'G2', 'G3', 'G4', 'G5')) to plt.xticks(('G1', 'G2', 'G3', 'G4', 'G5')), one reaches:

There's an xtick at -1 that is created, but not visible in the figure, which causes 'G1' to not show. This is even worse when the number of bars is less than 5, because multiple xticks between bars exist.

To conclude, this change might not be the best solution to this problem. The alternative to this is to return a different error message when setting labels without locs. What do you think it's the best course of action?

We test if ticks are in the view limit; see #12158 So I guess this function could work to check the current view limit and set the ticks based on what is in view. Maybe the test in #12158 should be factored into a private method so we can use it elsewhere rather than having multiple implementations. But I think that API would be clear enough....

That would fix the previous example. However, I don't think it would fix the underlying problem, which is clear in this example:

bar plots don't generate a single xtick per bar by default, and thus, setting the xticks without the ticks parameter can have this effect.

PS: It seems that the docs generation failed for the added file. I'll fix this asap. A commit squash might be need, apologies.

There are certainly problems with setting tick labels, but again xticks is basically repro'ing the API of set_xticklabels (and set_xticks) so I don't think this should prevent us from exposing the API at the pyplot level.

So I guess I’m starting to lean against this PR. It seems rife for confusion to allow the user to specify the labels but not the ticks they expect them attached to. So labels would be optional, but values would not. But I’ve not gone back and parsed all the discussion.

One can indeed argue that setting labels without ticks is only really needed in rare circumstances and often creates confusion. It would thus also be a valid choice to not support it in the high-level pyplot API, but require to use Axes.ticklabels in such a case.

Technically even Axes.set_xticklabels wasn't needed, we could just have said "Manually create and set a FixedFormatter", but that was not the design choice taken...
I don't feel very strongly about this, though.

So instead of this PR, we should probably give a better error message for when the user tries to set the labels without positions (as suggested by timhoffm). Currently it outputs TypeError: object of type 'NoneType' has no len(), which is not very informative.

Would this be a preferred solution?

Put on the agenda of the dev call today.

I am strongly opposed to allowing labels only, and hence in favor of improving the error message. "Labels-only" is a gun pointed straight at the users foot.

The consensus is that that we do not want to expose stetting labels only on the pyplot interface. It's hardly needed and a common source of mistakes. Instead, we should error out cleanly.

@bluetrickpt Would you like to contribute a PR with a better error message?

Sure, I can do that either today or tomorrow. I'll probably do on a different PR though, to clean the commit's log.