Repository navigation
[Bug]: Line2D.set_linestyle treats dash pattern with None onoffseq as dashed #23437
Closed as not planned
Description
Bug summary
The logic for setting linestyle using a dash tuple, i.e. (offset, onoffseq), does not properly handle the case where onoffseq is None.
Code for reproduction
print(mpl.lines.Line2D([], [], linestyle=(0, None)).get_linestyle())Actual outcome
'--'
Expected outcome
Ideally, dash values would roundtrip, so the return would be (0, None). Even when the dash sequence is not None, a lot of information is lost when this property is queried.
But more narrowly, (0, None) draws a solid line, so the return value should be '-'.
Additional information
The main consequence here is that the line's capstyle appears to conditionally read from solid_capstyle or dash_capstyle depending on the get_linestyle return value.
Matplotlib Version
3.5.2
Activity
oscargus commented on Jul 19, 2022
I can try to make sure that this is handled properly as part of #23056
github-actions commented on Dec 15, 2025
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!
timhoffm commented on Dec 16, 2025
The point here is simply that every dash pattern is returned as "--":
matplotlib/lib/matplotlib/lines.py
Lines 1177 to 1185 in b70e324
The question is what does "--" communicate here. Technically, it's "some kind of dash pattern". It does not analyze the pattern and try to give back a more suitable string. For example, linestyle=(0, plt.rcParams["lines.dotted_pattern"])) and linestyle=":" are identical, but yield "--" vs. ":". So, I don't think it's justified to fix the special case (0, None) here.
I'm inclinded to do nothing for this special case. In general, the utility of the current return value is questionable. And we may want to redesign this. See #29304.
While we could document the current behavior.
If the linestyle was specified as a string, the short form (one of "-", ":", "--", "-.") is returned. Empty linestyles are returned as "None". If the linestyle was specified as a dash pattern, "--" is returned.I'm concerned that the documentation would make more people use this, which means they get affected by a cleanup.
TBH this is badly designed and worse grown API, but the fix must be more substantial.
I'm closing and think we should move on with #23437. Feel free to create a PR with a documentation of the behavior as stated above if you think we should do that.