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
{{ message }}
Repository navigation
[ENH]: Add Independent xlabelpad and ylabelpad Options to rcParams #28860
Currently, we can only set a uniform axes.labelpad, which applies the same padding for both the x-axis and y-axis labels.
I am aware that it is possible to adjust the labelpad for the x and y labels independently using set_xlabel(..., labelpad=x_pad) and set_ylabel(..., labelpad=y_pad) in plotting code. However, would it be better to add separate options in rcParams to set the padding for x and y labels independently, similar to how xtick.major.pad and ytick.major.pad work?
While fundamentally reasonable, this is a bit more complicated because we need to keep backward compatibility with axes.labelpad.
We do have xaxis.labellocation / yaxis.labellocation. So the proper place would be xaxis.labelpad / yaxis.labelpad. But since we already have axes.labelpad it's a bit more difficult to handle consistently. One needs to define precedence rules so that existing use cases are not broken. Any implementation attempt must be aware of this.
@Kaustbh this should best build on top of the precedence mechanism added to _val_or_rc() introduced in #29481.
Unfortunately, we currently have a significant review backlog, which is why that PR is not yet in and the mechanism cannot be used. But you could start from that branch and rebase when that PR gets merged.
Activity
timhoffm commentedon Sep 24, 2024
While fundamentally reasonable, this is a bit more complicated because we need to keep backward compatibility with
axes.labelpad.We do have
xaxis.labellocation/yaxis.labellocation. So the proper place would bexaxis.labelpad/yaxis.labelpad. But since we already haveaxes.labelpadit's a bit more difficult to handle consistently. One needs to define precedence rules so that existing use cases are not broken. Any implementation attempt must be aware of this.Kaustbh commentedon Feb 10, 2025
Hi @timhoffm, I’d love to give this a try while ensuring backward compatibility by implementing clear precedence rules.
timhoffm commentedon Feb 10, 2025
@Kaustbh this should best build on top of the precedence mechanism added to
_val_or_rc()introduced in #29481.Unfortunately, we currently have a significant review backlog, which is why that PR is not yet in and the mechanism cannot be used. But you could start from that branch and rebase when that PR gets merged.
Kaustbh commentedon Feb 16, 2025
Okay I will start working on it.
Kaustbh commentedon Mar 12, 2025
Hi @timhoffm I have added the new
rcParams, just waiting for the PR #29481 to get merged.