You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
to change only the appearance of the ticks. Note that likely the get/set on ticks is inserted here because we have a warning that set_xticklabels chages to a fixed formatter and should only be used with after set_xticks.
The fundamental problem is that this changes to a fixed locator and formatter, which is an unintended side effect if I only want to rotate labels. Additionally, one can get caught up in the lazy determination of the ticks.
It's hard to distinguish between this sort of code and legitimate set_xticklabels calls. I don't think we can be more helpful with runtime warnings.
Proposed fix
A radical suggestion is to take away styling capability from set_xticklabels and instead direct people to tick_params(). The need for set_xticklabels (with it's major intent to set a fixed format - mainly for categorical values) is reduced since you can pass them as x values (plt.bar(['apples', 'peaches'], [1, 3])). I assume there are very few cases that people want a fixed formatter and adapt the style - which would be the only legitimate use for set_xticklabels(labels, rotation=90). They would need to go the extra mile and style separately (set_xticklabels(labels); tick_params('x', rotation=90)). But that might be worth it for removing quite a big foot canon.
The text was updated successfully, but these errors were encountered:
tick_params is not currently a replacement for set_{axis}ticklabels, right? It doesn't accept the arbitrary text kwargs. It's a little hard to follow all of the redirection, but one common task that I can't solve through tick_params is changing the label alignment after rotating.
Thanks for the hint. It's indeed true that tick_params is not a full replacement. So the first step would be to add API (possibly in tick_params) to allow full customization of the (default, i.e. applying to all tick instances of an axis) label style parameters.
So the first step would be to add API (possibly in tick_params) to allow full customization of the (default, i.e. applying to all tick instances of an axis) label style parameters.
xref #20644 since I opened that for label alignment & text properties in tick_params
Summary
In #23158 and similar cases before people use
to change only the appearance of the ticks. Note that likely the get/set on ticks is inserted here because we have a warning that
set_xticklabels
chages to a fixed formatter and should only be used with afterset_xticks
.The fundamental problem is that this changes to a fixed locator and formatter, which is an unintended side effect if I only want to rotate labels. Additionally, one can get caught up in the lazy determination of the ticks.
It's hard to distinguish between this sort of code and legitimate
set_xticklabels
calls. I don't think we can be more helpful with runtime warnings.Proposed fix
A radical suggestion is to take away styling capability from
set_xticklabels
and instead direct people totick_params()
. The need forset_xticklabels
(with it's major intent to set a fixed format - mainly for categorical values) is reduced since you can pass them as x values (plt.bar(['apples', 'peaches'], [1, 3])
). I assume there are very few cases that people want a fixed formatter and adapt the style - which would be the only legitimate use forset_xticklabels(labels, rotation=90)
. They would need to go the extra mile and style separately (set_xticklabels(labels); tick_params('x', rotation=90)
). But that might be worth it for removing quite a big foot canon.The text was updated successfully, but these errors were encountered: