There are two tests that are currently failing and need a rewrite.

1. test_axes.py::test_contour_hatching:

   Previous Behavior

   In collections, hatchcolor is set along with edgecolor.

   In the cases where edgecolors is explicitly specified by the user, hatchcolor is set to the first color in edgecolors and it also uses the alpha value specified by the user. However, if edgecolors is not specified, hatchcolor uses mpl.rcParams['hatch.color'] for the color, but it doesn't use the alpha value specified by the user.

   New Behavior

   The new implementation in this PR has hatchcolor separated from edgecolor and it uses the alpha value specified by the user, regardless of whether edgecolors is specified or not.

   Reason for New Behavior

   In the above test, alpha is set to 0.5 and edgecolors is not specified. Ideally, the hatch should have an alpha value of 0.5, but it actually has the default alpha value of 1.0.

   alpha works on hatchcolor when edgecolors is specified. Therefore, I believe that it should also work when edgecolors is not specified.

2. test_backend_bases.py::test_uses_per_path This requires a small change in the parameters passed to _iter_collection, corresponding to hatchcolors.

   --- a/lib/matplotlib/tests/test_backend_bases.py
   +++ b/lib/matplotlib/tests/test_backend_bases.py
   @@ -35,7 +35,7 @@ def test_uses_per_path():
               rb._iter_collection(
                   gc, range(len(raw_paths)), offsets,
                   transforms.AffineDeltaTransform(master_transform),
   -                   facecolors, edgecolors, [], [], [False],
   +                   facecolors, edgecolors, [], [], [], [False],
                   [], 'screen')]
           uses = rb._iter_collection_uses_per_path(
               paths, all_transforms, offsets, facecolors, edgecolors)

Pinging @story645 for review

Sorry for delay, will try to review but please add some tests.

Also this should probably go in before #27937 b/c I agree that it'll probably clean that one up.

For this change we need to make sure both:

• Anyone calling the backend methods without the new input value needs to not be broken (so the new keyword needs to be last and optional)
• Anyplace we call the backend methods internally we need to be forgiving of backends that have not adopted the new signature (we should have an example of using inspect.signature to manage this)

This will also need a lot of documentation (both notifying third-party backends the expected API is changing) and announcing the new feature to users (with lots of examples).

Could I also go ahead with rewriting the two tests that are failing?

Could I also go ahead with rewriting the two tests that are failing?

why are they failing? never mind, went and looked. So for this test:

TypeError: RendererBase._iter_collection() missing 1 required positional argument: 'offset_position'

It shouldn't be failing. This is what @tacaswell was talking about that you want to make sure the code is backwards compatible.

The test contour_hatch also seems like it should still pass, is there a reason it shouldn't?

Could I also go ahead with rewriting the two tests that are failing?

why are they failing?

The initial comment explains the reason

Sorry, I updated while you posted. For the tests:

However, if edgecolors is not specified, hatchcolor uses mpl.rcParams['hatch.color'] for the color, but it doesn't use the alpha value specified by the user.
In the above test, alpha is set to 0.5 and edgecolors is not specified. Ideally, the hatch should have an alpha value of 0.5, but it actually has the default alpha value of 1.0.

I think the user specified alpha should also be propagated to hatchcolors, w/ the same priority rules as color and edgecolor, which should then make the test pass.

This requires a small change in the parameters passed to _iter_collection, corresponding to hatchcolors.
these should be optional for backwards compatibility and therefore still pass

It may be simpler to work out what the non-vectorized version of this API looks like (so do just the classes in pathes.py) first and then do the collection-based ones in a follow on PR.

Thanks @Impaler343 for going with us through the lengthy discussion and design process.