Skip to content
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.

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

Inconsistent linestyle specifications between Line2D and Patch artists #2136

Closed
WeatherGod opened this issue Jun 18, 2013 · 9 comments · Fixed by #3772
Closed

Inconsistent linestyle specifications between Line2D and Patch artists #2136

WeatherGod opened this issue Jun 18, 2013 · 9 comments · Fixed by #3772
Milestone

Comments

@WeatherGod
Copy link
Member

Just noticed that to get a dashed line in a line plot:

plt.plot([1, 2, 3, 4], [1, 2, 3, 4], '--')

is completely different from how to specify a line style elsewhere, such as bar():

plt.bar([1, 2, 3, 4], [1, 2, 3, 4], ls='dashed')

It would make sense to me to normalize these two specifications together so that either "accent" of linestyle specifications would work anywhere a "linestyle" argument is accepted.

@pelson
Copy link
Member

pelson commented Sep 20, 2013

👍

@ninjasoul
Copy link

Hi. I would like to look into this issue. I am fairly new to Python and would love to take this opportunity to learn more about contributing to Python open-source projects.
Just wondering if it would require any C knowledge?

@WeatherGod
Copy link
Member Author

That would be great! This one will be a toughie. Not only will it require
code work, but documentation and tests will be needed as well.

We have a developer guide on our website that gives a basic idea on how to
contribute to matplotlib. Every project is a little different, but is
usually documented.

@ninjasoul
Copy link

Thanks. I will look into the developer guide.

@lennart0901
Copy link
Contributor

ninjasoul are you still looking into this?
Otherwise, I'd take a shot.

@ninjasoul
Copy link

lennart0901 go ahead. I've not been able to pursue this.

@lennart0901
Copy link
Contributor

The api is rather inconsistent with respect to linestyles and dash patterns.
Before I'm going to implement something there, I need some clarification.

  • In collections.py linestyles are converted to dash patterns. Those are also returned be the get method.
  • In lines.py the dash pattern is in dashes "property". if dashes is set, the linestyle is "dashed".
  • patches do not support dashes at all at the moment.

How much backward compatibility should be preserved? To me it makes most sense to change either the collections or lines to reflect the same style, either convert to dashes or have a dashes property...

@WeatherGod
Copy link
Member Author

I would go with the approach of letting both forms of the linestyle
specifications be allowed in both places. This maintains backwards
compatibility and lets users use to either form "get what they expect".

I wouldn't worry about patches at the moment.

On Tue, Jul 15, 2014 at 5:44 AM, lennart0901 notifications@github.com
wrote:

The api is rather inconsistent with respect to linestyles and dash
patterns.
Before I'm going to implement something there, I need some clarification.

  • In collections.py linestyles are converted to dash patterns. Those
    are also returned be the get method.
  • In lines.py the dash pattern is in dashes "property". if dashes is
    set, the linestyle is "dashed".
  • patches do not support dashes at all at the moment.

How much backward compatibility should be preserved? To me it makes most
sense to change either the collections or lines to reflect the same style,
either convert to dashes or have a dashes property...


Reply to this email directly or view it on GitHub
#2136 (comment)
.

@lennart0901
Copy link
Contributor

It did not mean I want to remove any way one can specify line/dash-patterns.
The question is what the getter-methods should return.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants