dashes are just a more limited form of linestyles. Actually, they are no more than:
def set_dashes(self, seq):
if seq == (None, None) or len(seq) == 0:
self.set_linestyle('-')
else:
self.set_linestyle((0, seq))
I propose to soft-deprecate dashes in favor of linestyle. Dashes are redundant and thus only increase the API complexity without any benefit. OTOH I don't think we should deprecate dashes because there might be quite a bit of code out there using it.
Specific actions for this task:
linestyle should directly accept a dash pattern. - It currently only accepts (offset, dash_pattern).
Change all internal code and examples to use set_linestyle.
In set_dashes, recommend to use set_linestyle instead.
seaborn uses dashes in lineplot so it would be best if this deprecation could be as soft as possible.
One point I would make is that the line._linestyle attribute does not track all of the information provided about how to draw the dashes:
def set_linestyle(self, ls):
if isinstance(ls, str):
ds, ls = self._split_drawstyle_linestyle(ls)
if ds is not None:
self.set_drawstyle(ds)
if ls in [' ', '', 'none']:
ls = 'None'
cbook._check_in_list([*self._lineStyles, *ls_mapper_r], ls=ls)
if ls not in self._lineStyles:
ls = ls_mapper_r[ls]
self._linestyle = ls
else:
self._linestyle = '--'
If you're going to be modifying the linestyle code to take the dash patterns directly, it might be good to fix how that works.
@mwaskom thanks for the comment. Which untracked information are you referring to specifically? Note that passing the drawstyle as part of the linestyle has been deprecated in 3.1 (#12442) and is removed for 3.3.
Sorry, I mean that any kind of quantitative dash pattern (passed to linestyle or dashes) gets stored as the simple string "--", with no obvious public access to the actual dash sequence.
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!
Activity
mwaskom commented on May 23, 2020
seaborn uses dashes in lineplot so it would be best if this deprecation could be as soft as possible.
One point I would make is that the line._linestyle attribute does not track all of the information provided about how to draw the dashes:
def set_linestyle(self, ls): if isinstance(ls, str): ds, ls = self._split_drawstyle_linestyle(ls) if ds is not None: self.set_drawstyle(ds) if ls in [' ', '', 'none']: ls = 'None' cbook._check_in_list([*self._lineStyles, *ls_mapper_r], ls=ls) if ls not in self._lineStyles: ls = ls_mapper_r[ls] self._linestyle = ls else: self._linestyle = '--'If you're going to be modifying the linestyle code to take the dash patterns directly, it might be good to fix how that works.
timhoffm commented on May 25, 2020
@mwaskom thanks for the comment. Which untracked information are you referring to specifically? Note that passing the drawstyle as part of the linestyle has been deprecated in 3.1 (#12442) and is removed for 3.3.
mwaskom commented on May 25, 2020
Sorry, I mean that any kind of quantitative dash pattern (passed to linestyle or dashes) gets stored as the simple string "--", with no obvious public access to the actual dash sequence.
QuLogic commented on May 26, 2020
See also #17316 and #11797.
github-actions commented on Feb 16, 2026
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 Feb 16, 2026
Still worth considering, but not trivial and not urgent.