It may make sense to make this part of a general consolidation ofget_linestyle across Artists. There are 3 fundamentally reasonable ways to reoport linstyle back:

• just return what was input toset_linestyle
• normalize to a simplified string - all dashes become-- and the actual pattern would have to requested fromget_dashes
• always normalize to a dash pattern (unscaled)

It seem we do most of this for the different artists#29302 (comment).

I haven't thought too deep, but don't see a clear winner. There are pros and cons for all of them. So it might be an option the add a more generalget_linestyle(mode=) argument to choose the return type. This would reduce current differences to different defaults and open up a relatively pain-free migration path if desired.

Thoughts welcome.

I would vote for either getting back what you put in or normalising to unscaled dash pattern. I can’t see the value of normalising to a string because you lose information. The OPs of#23437 and#17316 object to the current Line2D behaviour. Also#23056 (comment).

Normalising to the dash pattern would seem consistent with the fact that colours normalise to RGBA. Presumably it gives some efficiency saving when it is copied across to another object such as a legend handle, as you do not need to translate to the pattern on the new artist.

Of course normalising to unscaled dash pattern is the one that we’re not currently doing anywhere 😄

Normalising to the dash pattern would seem consistent with the fact that colours normalise to RGBA.

This sounds reasonable, and I'd be in favor of normalizing to a canonical representation. However, I'm not clear that the dash pattern is such a canonical representation in the same way RGBA is for color

• The dash patten is not intuitive to understand - basically you have to read the documentation.
• The representation of solid lines and no lines, is not straight forward.
• Could we have other linestyles in the future that cannot be represented by the dash pattern?

An alternative would be normalizing to

• 'solid' for solid lines
• 'none' for no lines
• a dash pattern for all other cases

Likely 'solid' and 'none' need special checks and code paths anyway, so there's not really a benefit in trying to express a line style without dashes as a formal dash pattern.

This seems like it might be related to#23056, whose discussion never really finished.

Also related:#19300,#17483

It's all quite a mess.

Fundamentally, I believe we need to decide:

• Do we want a canonical representation of a linestyle?
  I claim yes, at least internally, we want to have a normalized form and not need to care about "-" vs. "solid" vs. ...
• How does a canonical linestyle representation look like?
  • always a dash pattern (?)
  • 'none' or 'solid' or dash-pattern
  • aLineStyle class
  • ...
• What do we want to return onget_linestyle()?

I suggest we discuss these on a green field ("What would be a good design") and only afterwards see how we can migrate there.

FYI that there is this old PR suggesting to make a LineStyle class:#18664

I think we've moved away from necessarily wanting classes for all conecptual types. One of the main arguments was a concise definition of what values are accepted. We can now encode this using the typing system. That's not to say classes are completely off the table. If there's enough related functionality a class is still an option (e.g. the existingMarkerStyle is such a case).