FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

[MNT]: de-duplicate hatch validation · Issue #24797 · matplotlib/matplotlib · GitHub

Repository navigation

[MNT]: de-duplicate hatch validation #24797

Description

Summary

In #17926 code to validate hatches got added to the hatch module:

def _validate_hatch_pattern(hatch):
valid_hatch_patterns = set(r'-+|/\xXoO.*')
if hatch is not None:
invalids = set(hatch).difference(valid_hatch_patterns)
if invalids:
valid = ''.join(sorted(valid_hatch_patterns))
invalids = ''.join(sorted(invalids))
_api.warn_deprecated(
'3.4',
removal='3.8', # one release after custom hatches (#20690)
message=f'hatch must consist of a string of "{valid}" or '
'None, but found the following invalid values '
f'"{invalids}". Passing invalid values is deprecated '
'since %(since)s and will become an error %(removal)s.'
)

and there's near identical code in rc validation that went in in #4686:

def validate_hatch(s):
r"""
Validate a hatch pattern.
A hatch pattern string can have any sequence of the following
characters: ``\ / | - + * . x o O``.
"""
if not isinstance(s, str):
raise ValueError("Hatch pattern must be a string")
_api.check_isinstance(str, hatch_pattern=s)
unknown = set(s) - {'\\', '/', '|', '-', '+', '*', '.', 'x', 'o', 'O'}
if unknown:
raise ValueError("Unknown hatch symbol(s): %s" % list(unknown))
return s

They diverge slightly in that the hatch version has a deprecation warning but I think it should also apply to the rc version?

Proposed fix

Make the validation function in hatch.py the canonical validator and either deprecate the rcsetup validation function or turn it into a thin shim over the one in hatch.

Activity

  1. oscargus commented on Dec 21, 2022

    Member

    Also relevant: #20690 and #21108 (as in the "proper" fix is probably to introduce a HatchStyle and then have a single validator).

  2. anntzer commented on Jan 1, 2023

    Contributor

    Assuming we want to allow custom hatches at some point (which seems to be the general agreement in #20690, and I tend to agree as well), the practical solution may just be to get rid of validate_hatch and allow any string in rcParams (possibly later exploding at runtime), just like we allow any string for image.cmap (and not just known colormap names) as the corresponding colormap may well not be registered yet (e.g. if reading from matplotlibrc and registering the colormap at runtime).

  3. story645 commented on Jan 1, 2023

    MemberAuthor

    just like we allow any string for image.cmap

    why not do something like the marker API, where either pass a string that's currently valid or a 'HatchStyle' object?

  4. anntzer commented on Jan 2, 2023

    Contributor

    That won't work if you want to specify in your matplotlibrc a hatchstyle that'll be defined by a third-party library.

  5. story645 commented on Apr 14, 2024

    MemberAuthor

    That won't work if you want to specify in your matplotlibrc a hatchstyle that'll be defined by a third-party library.

    I don't know if anyone's opened an issue for this, but on one of the calls we've discussed the idea of having a registry system for hatches, kinda like how we do for colormaps? Which I think ties into your suggestion on how we do validation like we do for cmap.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions


      Back | FazBrowse Home | New Git URL