(De-Duplication) linking validate hatch from hatch module

[ShivamPathak99]

PR summary

issue #24797
Applying the discussed changes in rcsetup

PR checklist

• "closes [MNT]: de-duplicate hatch validation #24797" is in the body of the PR description to link the related issue
• new and changed code is tested
• Plotting related features are demonstrated in an example
• New Features and API Changes are noted with a directive and release note
• Documentation complies with general and docstring guidelines

[ShivamPathak99]

I think py:obj reference target not found: rcsetup.validate_hatch is causing test fails.
as I have changed validate_hatch into a alias name.

validate_hatch = _validate_hatch_pattern

Any fixes for this error?

[tacaswell]

rcparams is imported very early in import process so this change adds a circular import (matplotlib/init.py -> rcparams.py -> hatch.py -> matplotlib/init.py).

If we want to do this merging, then the cannonical location needs to be in rcparams (as funny as that seems).

[story645]

If we want to do this merging, then the cannonical location needs to be in rcparams (as funny as that seems).

What about going the other direction and doing the validation at run time, which I think is kind of what @anntzer is suggesting in #24797 (comment) b/c it allows for setting third-party hatches in rcParams.

[story645]

Ok, so I'm just gonna summarize my understanding of three options:

1. arbitrary string + runtime validation in HatchModule [MNT]: de-duplicate hatch validation #24797 (comment))
   • pro: makes it easier to allow third party hatches
   • con: validation is done in runtime - but may be able to call out inside the RcParams init for this the way we do other runtime Rc Validation
2. validation in RcParam & HatchModule calls out to rcParam as needed
   • pro: avoids circular dependency
   • con: separation of concerns- valid hatches are effectively defined in RcParam rather than in hatch, so have to call out to rcParam for runtime validation. May end up needing two chains of fallback logic for external Hatchs -> inside RcParams and inside Hatches
3. leave duplicated validation functions:
   • pro: no changes needed
   • con: two sources of truth for valid hatch specs so increased potential for drift/inconsistency and maintenance burden of keeping (remembering to keep) the two specs in sync

[story645]

@ShivamPathak99 we discussed this on the call and decision was either do 2. or 3.

[tacaswell]

This is an subtle API change that needs to be document as currently

b.set_hatch(('x','x'))

works. The docstring on Patch.set_hatch is not clear about the type on the input should be.

We do run the hatches through an lrucache so only hashable things work (and it looks like we used as a key in a dictionary before that).

[ShivamPathak99]

Working on it,
I'm a bit lost on -

We do run the hatches through an lrucache so only hashable things work (and it looks like we used as a key in a dictionary before that).

Could you break it down for me

[tacaswell]

matplotlib/lib/matplotlib/path.py

Lines 1025 to 1035 in 199c31f

	@staticmethod
	@lru_cache(8)
	def hatch(hatchpattern, density=6):
	"""
	Given a hatch specifier, *hatchpattern*, generates a `Path` that
	can be used in a repeated hatching pattern. *density* is the
	number of lines per unit square.
	"""
	from matplotlib.hatch import get_path
	return (get_path(hatchpattern, density)
	if hatchpattern is not None else None)

Is part of the code path between Patch.set_hatch and rendering a hatched patch. The lru_cache means we will avoid re-computing the hatch path. The lru_cache is backed by a dictionary (eventually) with the function parameters as the key so only inputs that are hashable can be used.

[ShivamPathak99]

validation in RcParam & HatchModule calls out to rcParam as needed

• pro: avoids circular dependency

Sorry for delay, figuring out option 2.

2. validation in RcParam & HatchModule calls out to rcParam as needed

   • pro: avoids circular dependency
   • con: separation of concerns- valid hatches are effectively defined in RcParam rather than in hatch, so have to call out to rcParam for runtime validation. May end up needing two chains of fallback logic for external Hatchs -> inside RcParams and inside Hatches

[ShivamPathak99]

Have I done it right, some tests are still failing.
Any suggestions ?''🤔

[rcomer]

@ShivamPathak99 some of the tests are a bit flakey. I’ve re-run the failed one so let’s see how it goes this time. 🤞

[ShivamPathak99]

Why codecov/project/tests failing ?