I had to go spelunking in the code to know that this was even correct.

Believe you me I understand THAT feeling!

I will update the doc strings (maybe tomorrow, maybe Thursday) and re-ping you here.

@dopplershift I updated the docs of set_marker and __init__ and decided that I disagreed with the remaining flake8 criticisms. I will 'fix' them if you require it, but I think it's extremely legible as is and that obeying the line length requirement would actually reduce legibility in this case.

Could you also add a (smoke) test that this does not blow up?

👍 modulo fixing the style issues and adding a test.

@tacaswell Can you explain what a smoke test means? You are talking to a programming scientist, not a programmer :)

What should I be testing? That Line2D, when given an unusual marker, actually copies the marker? The previous implementation would have worked for all the "standard" markers.

Sorry for the jargon, it is from "turn it on and see if it smokes!".

As your original bug generated a stack trace when it should not have so the minimal test is if you can run that code and not raise (e.g. does not start smoking because it blew up).

A better and more complete test is verifying that it also actually set the marker to what it should be.

@tacaswell If I add the test, aren't we saying that the weird thing I did is in a nebulous not-supported-but-not-NOT-supported thing?

OK. I actually was able to reduce my problem even further:

#!/usr/bin/env python3

import matplotlib
import matplotlib.pyplot as plt
from matplotlib.markers import MarkerStyle

fix, ax = plt.subplots()
plt.errorbar([1,2,3],[3,4,5], yerr=[0.5,0.5,0.5], marker=MarkerStyle('d'), linestyle='none', color='green')
plt.show()

which has nothing to do with my transform. In 3.2.2 this throws a TypeError for either errorbar or plot, surprisingly, though scatter is OK. I added a test lib/matplotlib/tests/test_axes.py::test_marker_as_MarkerStyle to make sure that this functionality is and remains supported. This test does not test that the marker is correctly copied, which is what the actual code part of this PR does.

The good news is that 3.3.2 already passes / can run this mwe.

Modulo the plt vs ax change, the test looks conceptually right!

What you did is definitely in the "supported" category of things.

OK, Here's another very strange thing, but it may warrant its own, separate issue. I suspected that my problem with my explicit legend example was with Line2D. So I wrote this little example

#!/usr/bin/env python3

import matplotlib
import matplotlib.pyplot as plt
import matplotlib.lines as mlines
from matplotlib.markers import MarkerStyle

print(f"{matplotlib.__version__=}")
print(f"{matplotlib.get_backend()=}")

# But when I use it in errorbar
fig_ref = plt.figure()
fig_ref.add_artist(mlines.Line2D([0.25,0.75],[0.25,0.75], marker='d'))
fig_test = plt.figure()
fig_test.add_artist(mlines.Line2D([0.25,0.75],[0.25,0.75], marker=MarkerStyle('d')))
plt.show()

Which outputs

matplotlib.__version__='3.2.2'
matplotlib.get_backend()='MacOSX'

And then I wrote a little test that would check for that difference in test_lines.py:

@check_figures_equal()
def test_marker_as_markerstyle_comparison(fig_test, fig_ref):
    fig_ref.add_artist(mlines.Line2D([0.25,0.75],[0.25,0.75], marker='d'))
    fig_test.add_artist(mlines.Line2D([0.25,0.75],[0.25,0.75], marker=MarkerStyle('d')))

and the test passes!

> pytest lib/matplotlib/tests/test_lines.py::test_marker_as_markerstyle_comparison
=========================== test session starts ============================
platform darwin -- Python 3.8.5, pytest-6.1.0, py-1.9.0, pluggy-0.13.1
rootdir: /Users/evanberkowitz/src/matplotlib, configfile: pytest.ini
collected 3 items

lib/matplotlib/tests/test_lines.py ...                               [100%]

============================ 3 passed in 2.62s =============================

What?! I tried adding to the above test

    fig_ref.savefig('ref')
    fig_test.savefig('test')

to the test to see if they're REALLY the same or not and sure enough, the both look like this:

What gives?

Note that I observe a difference in 3.2.2 but not the latest that my PR is written against.

That was fixed in #16692, I think.

OK, that seems correct. I will not add my test then.

@QuLogic---as I mentioned in my comment towards the top of this PR, if you actually look at the code for the flake8 complaints and add a newline, the docstrings become harder to read. If you tell me that you understand that, then I will change them. Otherwise, I advocate ignoring those complaints.

We do not ignore flake8 arbitrarily. We have plenty of these lists wrapped, so I don't see how it is less legible.

Widows and orphans are known to typesetters to cause ugly looking or hard-to-read text. In this case the enormous amount of whitespace introduced by the orphans created by wrapping these only-slightly-over-length lines cause visual interruption. A linter usually doesn't take that sort of "global appearance" into account. But I'll change it against my better judgement.

Um... now eslint simply failed to set up? I don't think this one was my fault.

eslint reran and succeeded, so all tests have now passed.

But I'll change it against my better judgement.

On projects that only have a handful (or just one) person working on them it is plausible to have use your judgement on the formatting, but on a project the scale of Matplotlib (we have over 1k people who have touched the code in some way at this point!) we have to rely on automated tools to maintain any consistency in the codebase. It also means we can have the robot tell you the style is wrong than have a person tell you ;)

Thanks for finding and fixing this @evanberkowitz.

Congratulations on your first Matplotlib PR 🎉 hopefully we will hear from you again!

Glad to contribute. Hopefully there will never be further bugs for me to encounter ;) !