I have unified the doc-strings and refactored the line style verification a bit, so that all set_linestyle methods rely on the same code.

Question: it is "line style" in text, right? (Not "linestyle")

Problem: Collection does not actually support a way of having an empty line style as they store dash-patterns. The only way to currently get that is to set the line width to zero or the edge color to 'none'. Would it make sense to trick an empty line style by setting e.g. the line with to zero? Lines do store both _linestyle and _dashpattern, but Collection only _linestyle (always as a dash pattern).

So while now there is no error supplying e.g. ' ' as line style for a Collection (e.g. scatter plot) it still is not really supported.

I am not really sure if the dash length checks in the backend set_dashes is still required now? Is this supposed to be a user facing method? Currently, every time set_linewidth or set_dashes is called, there will be a check, so the only way (I can figure out) to get a hang is to set _linestyle or _dashpattern in a stupid way.

I would also like some input on the best format to normalize/store line-styles. Now, they are normalized to the "short" format '-', '--', '-.', ':', and 'none', but I think that the rcparam validator returns 'solid', 'dashed', ... 'none'. So which is the preferred way?

I guess the proper way to actually handle empty line styles in collections is to separate the line style and the dashes as in lines. Does anyone foresee any obvious drawbacks of this?

A major obstacle to the solution discussed yesterday is that Patches does not have get_dashes currently. Hence, it is not really possible to use the "warn on get_linestyle and say they should use get_dashes instead" approach as that will require a pin of the MPL version.

I made a PR to Seaborn mwaskom/seaborn#3400 but got stuck there. All other things seemed to work though.

To summarize, this PR unifies the handling of line styles so that get_linestyle returns a string of the line style pattern and get_dashes returns the dash pattern. It also unified the checking of line styles and dash patterns so that the same requirements are set on all, independent of class.

Earlier Patches and Collections returned the dash pattern for get_linestyle. Collections have aliased dashes so that it is currently returned there as well, but Patches does not have a get_dashes method.

The suggested procedure was to simply add a warning to Collection.get_linestyle for a few version stating that the output will change and the dash pattern info can be obtained through get_dashes. However, I forgot that the same applies to Patches, but there is no get_dashes for that.

(This also adds get_dashes to Lines and Patches. Earlier it was not possible to obtain the dash pattern for Line2D.)

To summarize:

Patch.get_linestyle earlier returned exactly what was passed as linestyle. Now, get_linestyle emits a warning that it will change, but I have no idea what is a good way to turn it off. (In the long run, get_linestyle should return the normalized line style string and get_dashes, the dash pattern.)

Collection.get_linestyle did always return the dash pattern. Now, this warns that it will change and that get_dashes (which has long existed) can be used to get the same result.

For Line2D and Patch, a get_dashes method is added which can be used to get the dash pattern.

I do not get the mypy error. Probably one would like to type get_dashes to not return LineStyleType? Or rather add LineStyleString and DashPatternType and combine those into LineStyleType for set_linestyle and then add the correct for get_dashes and later on get_linestyle?

It also strikes me that set_dashes is no longer valid for Collection. Should it be added as set_dashes = set_linestyle or should it be a method that actually only sets the dash pattern (and therefore making more sense, but also making it impossible to do `col.set_dashes('-')'?

What is the preferred way of normalized line styles? The "named" or the "symbols"? Also, which string should be used for an empty line style? (Right now it varies.)

It also strikes me that there is a difference between "dashes" and "dash pattern", where "dash pattern" is (offset, dashes). Hence, set_dashes and get_dashes are not reciprocal. Should there be a get_dash_pattern method? If so, this will cause some issues with Collection, which currently returns the dash pattern with get_dashes (and get_linestyle),

We should discuss this on a call as soon as 3.9 is branched.

@oscargus

To summarize, this PR unifies the handling of line styles so that get_linestyle returns a string of the line style pattern and get_dashes returns the dash pattern.
[...]
For Line2D and Patch, a get_dashes method is added which can be used to get the dash pattern.

I find this very unintuitive. I would strongly suggest making get_linestyle consistently return an exact representation of the actual line style, not a lossy string representation (i.e. adopt Line2D behaviour to Collections, not the other way round)!

Consider the following examples, where the current approach of get_linestyle causes very bad user experience:

from matplotlib import pyplot as plt
plt.figure(figsize=(3,2))
line1, = plt.plot([0,1],[0,3], ls=(0, [1,2,1,2,10,2]))
line2, = plt.plot([0,1],[0,2])
line3, = plt.plot([0,1],[0,1])


line2.set_linestyle(line1.get_linestyle())
# user now expects both lines to have identical linestyles,
# but because get_linestyle returns "--" this is not the case - very unexpected behaviour

ls = (0, [1,2])
line3.set_linestyle(ls)
print(line3.get_linestyle())
# prints "--" which is not the set value but a valid different linestyle - very unexpected

if line1.get_linestyle() == line2.get_linestyle() == line2.get_linestyle()
    ... # this is true even though all lines have completely different linestyles - very unexpected

Suggestion:

• Make get_linestyle consistently return exactly what was set as linestyle,
  such that it actually represents the linestyle correctly and line2.set_linestyle(line1.get_linestyle()) works as expected
• Optionally:
  • Keep the proposed get_dashes to return the dash pattern even if linestyle was set as string
  • Add get_linestyle_string to return the string representation (even if linestyle was set as on-off pattern). Because not all linestyles can be represented as string, the method may either raise an exception or have a special return value like --- (which is not a valid linestyle!) to distinguish between exact and approximate representations. However, I don't actually think such a method is need.

line2.set_linestyle(line1.get_linestyle())

If I'm not mistaken, with this PR using

line2.set_linestyle(line1.get_dashes())
# or the identical
line2.set_dashes(line1.get_dashes())

would also not work correctly, because get_dashes returns the scaled _dash_pattern and not the _unscaled_dash_pattern, but set_dashes = set_linestyle expects an unscaled pattern and applies the scaling (again (and again (and again))).

Suggestion:

• make get_dashes return the _unscaled_dash_pattern instead, because the scaling is internal and should not be exposed to the user.

This does a lot of things around linestyles/dashes. I have to say, I have lost what exactly we do here. There seems to be some internal code cleanup, some fixes, some additions, and some are breaking API changes. The latter seems controversial. Can we untangle the topics?