Would you like me to push another commit and PR that removes the offending extra line and whitespace (flake8 fail) or edit the PR?
Update: I edited the PR-staged code.

I see the other failures are because of two tests failing: one because my warning was triggered for test_legend_pathcollection_labelcolor_markfacecolor_cmap

        fig, ax = plt.subplots()
        facecolors = mpl.cm.viridis(np.random.rand(10))
        ax.scatter(
            np.arange(10),
            np.arange(10),
            label='#1',
            c=np.arange(10),
            facecolor=facecolors
        )

And the other because another warning was triggered.
That second one has been plaguing PRs since this morning: https://github.com/matplotlib/matplotlib/actions/workflows/tests.yml

=========================== short test summary info ============================
FAILED lib/matplotlib/tests/test_backends_interactive.py::test_interactive_backend[toolmanager-MPLBACKEND=wxagg-BACKEND_DEPS=wx] - Failed: Subprocess failed to test intended behavior
<frozen _collections_abc>:982: UserWarning: Treat the new Tool classes introduced in v1.5 as experimental for now; the API and rcParam may change in future versions.
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/runner/work/matplotlib/matplotlib/lib/matplotlib/tests/test_backends_interactive.py", line 232, in _test_interactive_impl
    assert result.getvalue() == result_after.getvalue()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError

I just raised issue #29131 about that one.
But I'll have to analyze the first test to see if it's failing only because of my intentional improvement in behavior.

Would you like me to push another commit and PR that removes the offending extra line and whitespace (flake8 fail) or edit the PR? Update: I edited the PR-staged code.

Yes, you've don this correctly: Please update this PR and do not create new ones on the same topic. You can choose whether to add additional commits or force-push a new version.

I tried out the test code that was failing
test_legend_pathcollection_labelcolor_markfacecolor_cmap

        fig, ax = plt.subplots()
        facecolors = mpl.cm.viridis(np.random.rand(10))
        ax.scatter(
            np.arange(10),
            np.arange(10),
            label='#1',
            c=np.arange(10),
            facecolor=facecolors
        )

As I suspected, facecolors doesn't do anything in that case, so my addition justifiably raises the warning. This, of course, alters the outcome from the assertion's previous expectation.
I will change the test to:

        fig, ax = plt.subplots()
        ax.scatter(
            np.arange(10),
            np.arange(10),
            label='#1',
            c=np.arange(10)
        )

which produces the indentical plot as before (I tested it with .canvas.tostring_rgb()).
However, I imagine that will not update all your online test suites. I hope you will approve my PR regardless.

That failing test was added in Commit 66ec3a0 .
I see the intention was to test if the label color in the legend is correctly set when using a colormap.
So I, instead, am only dropping the c argument in the test:

    fig, ax = plt.subplots()
    facecolors = mpl.cm.viridis(np.random.rand(10))
    ax.scatter(
        np.arange(10),
        np.arange(10),
        label='#1',
        facecolor=facecolors
    )

    leg = ax.legend(labelcolor='markerfacecolor')
    for text, color in zip(leg.get_texts(), ['k']):
        assert mpl.colors.same_color(text.get_color(), color)

This will let the random color assignment shine through, but it won't raise a warning. The only problem would be if a visual compare test were done with its old output.

I want to mention that I am working on an alternative branch where I add an ec (edge colors) arg to .scatter() that parallels c's functionality and would come before the current 'edgecolors' arg (which I bump to kwargs). This would make it explicit that c should not be used for specifically setting edge colors and return intuitive, symmetrical functionality to .scatter().

(timhoffm: accidental edit reverted)

@timhoffm, your edit to my comment above is full of good points.
I would still want to explore if I can add the functionality of having two independent colormap objects running in parallel, one for face and one for edge. Don't worry, I am treading extra carefully as I am aware that I am new here, plus I am proposing a much bigger shift than what @tacaswell already proposed.

@timhoffm, your edit to my comment above is full of good points.

Sorry for editing your comment. I intended to click "quote reply" but accidentally hit the wrong button 🐑. I've reverted the edit.

For reference, here is my comment:

I'm sceptical on this. c is primarily used for color mapping. With the current implementation of ScalarMappable you cannot have two independent color mappings (one for face and one for edge). Therefore, I don't see how ec could be parallel to c. Note also that ec already exists as an alias for edgecolors.

I would still want to explore if I can add the functionality of having two independent colormap objects running in parallel.

You should look into #28658 and #28428, which generalize the colormapping concept. The case of separate edgecolor mapping is not explicitly contained, but fits into that context.

Codecov doesn't like that in my test I wrote:

+     def get_next_color():
+         return 'blue'

I think it considers the output of that function as untested. But I was just following the lead of three tests above it, which it is also complaining about. Should I change my test, or ignore it?

The other failing check is build time taking over an hour (including the test suite, I think). I'm not sure that is because of something I did, though.

The AppVeyor check failed, but after reading the error logs, and doing the same workflow on my Mac, I believe it's a Windows problem unrelated to my change.

I rebased my branch but incidentally created duplicate commits on top. I should have used interactive rebase, sorry.

Is there anything else I can do to improve my Pull Request?

Anything else?

Thank you, @timhoffm

Thanks @NGWi, sorry it took so long to follow up, hope to see more contributions from you! 🥳

@story645 story645 added this to the v3.10.1 milestone Jan 3, 2025

You didn't trigger a backport, if this milestone was intentional.

Uch what's the command again? I think this should get back ported since it's just an error check, right?

@meeseeksdev backport to v3.10.x