8000 axhline/axvline don't use prop_cycle · Issue #14222 · matplotlib/matplotlib · GitHub
[go: up one dir, main page]
Skip to content

axhline/axvline don't use prop_cycle #14222

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
u55 opened this issue May 14, 2019 · 6 comments
Closed

axhline/axvline don't use prop_cycle #14222

u55 opened this issue May 14, 2019 · 6 comments
Labels
API: consistency

Comments

@u55
Copy link
Contributor
u55 commented May 14, 2019

Hi matplotlib developers,
axhline and axvline do not use the prop_cycle, and it seems to me that they should. Was this intentional?

import numpy as np
import matplotlib.pyplot as plt
from cycler import cycler

fig, ax = plt.subplots()
ax.set_prop_cycle(cycler(color=['r', 'g', 'y', 'm'], ls=['--']*4))
ax.plot(np.arange(9))
ax.axhline(4) # uses default styles instead of cycler
ax.axvline(4) # uses default styles instead of cycler
ax.plot(-np.arange(9))
plt.show()

Tested with matplotlib 3.0.3 and python 3.7.3 (Anaconda) on Windows 10.
@jklymak
Copy link
Member
jklymak commented May 14, 2019

Usually these are not meant to represent data, but rather some interesting value. Hence, I don't think they should participate in the cycle....

@u55
Copy link
Contributor Author
u55 commented May 14, 2019

@jklymak Thanks for the answer. I don't see the distinction between a single value and data (an array of values), but it sounds like your typical use-case is more like a configurable grid line or annotation, in which case I would expect the default color to be gray or black instead of 'tab:blue', so as to distinguish it from data lines plotted with the default color cycle.

But if the consensus is that the current behavior is desired, I will close the issue.

@jklymak
Copy link
Member
jklymak commented May 15, 2019

Yeah, that's exactly how I think of it. I'd be for the default being black, but....

FWIW, I think you can manually use the cycle colors...

@u55
Copy link
Contributor Author
u55 commented May 15, 2019

FWIW, I think you can manually use the cycle colors...

Do you mean something more sophisticated than ax.axhline(4, color='g', ls='--') ?

@u55 u55 closed this as completed May 25, 2019
@tacaswell
Copy link
Member

@u55 You can do things like

for j, stys in enumerate(my_cycler):
    ax.axhline(j, **stys)

I think @jklymak 's analysis is correct and a common usage is easily configurable "extra" grid lines.

The default color ends up falling through to rcParams['lines.color'] which is by default 'C0' which is not great for exactly the reasons you state @u55 .

However changing the default color of axvline would be an API change and unfortunately we missed this when we did 2.0. If we had noticed this when we were going through that process I suspect we would have changed axvline and axhline to match the grid color by default.

At this point, I am concerned about changing default colors ad-hoc as once we start to go down that route it opens up a rather scary can of worms....

@u55
Copy link
Contributor Author
u55 commented May 26, 2019

@tacaswell Yeah, I also wouldn't expect you to change the default color now, at least not until the next major version bump (4.0).

@timhoffm timhoffm mentioned this issue May 26, 2019
Open
@QuLogic QuLogic mentioned this issue Mar 9, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
API: consistency
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@tacaswell @story645 @jklymak @u55
0