ax.set_xticks([1, 2, 3], labels=['a', 'b', 'c'])
instead of
ax.set_xticks([1, 2, 3])
ax.set_xticklabels(['a', 'b', 'c'])
Discourage using set_ticklabels(). - I think it's too widely used, so that we cannot deprecate it.
Further comments
This should make set_xticks() more similar/equal to pyplot.xticks(), which already has the labels parameter.
To be sorted out:
whether we want to support labels only (set_ticks(labels=['a', 'b', 'c'])
the return value of get_xicks(), which only returns the values, whereas pyplot.xticks() without parameters returns ticks, labels. This is a somwhat annoying asymmetry, but probably has to be left as is.
some more details.
          
@mwaskom Thanks, that's a valid point I did not realize. However, I'm only proposing to discourage set_xticklabels() not remove it.
Discourage using set_ticklabels(). - I think it's too widely used, so that we cannot deprecate it.
So your example would still work.
          
If we are going to introduce a new API I would suggest perhaps a {tick: label, ...} mapping?  That looks the most pythonic to me...  Perhaps also support a list of [(tick, label), ...] pairs just in case someone really wants to have two ticks at the same location.  The advantage of either format is that they immediately enforce the fact that there should be as many ticks as labels.
          
I'm buying the structured data type for xticks.  it nicely solves the "properties should be one parameter" issue so that we can do ax.set(xticks=zip(ticks, labels)). On the downside we have the asymmetry betweeen set_xticks and get_xticks.
My main concern is that plt.xticks(positions, labels) and ax.set_xticks(zip(positions, labels)) will have different APIs and I have no good idea how to make that bearable.