I have unified the doc-strings and refactored the line style verification a bit, so that allset_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, butCollection only_linestyle (always as a dash pattern).

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

I am not really sure if the dash length checks in the backendset_dashes is still required now? Is this supposed to be a user facing method? Currently, every timeset_linewidth orset_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 haveget_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 Seabornmwaskom/seaborn#3400 but got stuck there. All other things seemed to work though.

To summarize, this PR unifies the handling of line styles so thatget_linestyle returns a string of the line style pattern andget_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 forget_linestyle. Collections have aliaseddashes so that it is currently returned there as well, but Patches does not have aget_dashes method.

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

(This also addsget_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 aslinestyle. 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 andget_dashes, the dash pattern.)

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

ForLine2D andPatch, aget_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 typeget_dashes to not returnLineStyleType? Or rather addLineStyleString andDashPatternType and combine those intoLineStyleType forset_linestyle and then add the correct forget_dashes and later onget_linestyle?

It also strikes me thatset_dashes is no longer valid forCollection. Should it be added asset_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 andget_dashes are not reciprocal. Should there be aget_dash_pattern method? If so, this will cause some issues withCollection, which currently returns the dash pattern withget_dashes (andget_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 thatget_linestyle returns a string of the line style pattern andget_dashes returns the dash pattern.
[...]
ForLine2D andPatch, aget_dashes method is added which can be used to get the dash pattern.

I find this very unintuitive. I would strongly suggest makingget_linestyle consistently return anexact representation of theactual 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 ofget_linestyle causesvery bad user experience:

frommatplotlibimportpyplotaspltplt.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 behaviourls= (0, [1,2])line3.set_linestyle(ls)print(line3.get_linestyle())# prints "--" which is not the set value but a valid different linestyle - very unexpectedifline1.get_linestyle()==line2.get_linestyle()==line2.get_linestyle()    ...# this is true even though all lines have completely different linestyles - very unexpected

Suggestion:

• Makeget_linestyle consistently return exactly what was set as linestyle,
  such that it actually represents the linestyle correctly andline2.set_linestyle(line1.get_linestyle()) works as expected
• Optionally:
  • Keep the proposedget_dashes to return the dash pattern even if linestyle was set as string
  • Addget_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 identicalline2.set_dashes(line1.get_dashes())

would also not work correctly, becauseget_dashes returns the scaled_dash_pattern and not the_unscaled_dash_pattern, butset_dashes = set_linestyle expects an unscaled pattern and applies the scaling (again (and again (and again))).

Suggestion:

• makeget_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?