Let's raise instead. Semantically, hatch=[] does not make sense. Users should use None for "no hatch".

That makes sense semantically — None is the canonical way to disable hatching.
However, in practice, there are scenarios where hatch can be constructed programmatically (e.g., through loops, Giles, or data pipelines). In such cases, it may naturally or unintentionally evaluate to an empty list — for example, via something like config.get("hatch", []). Raising an error in these situations could make otherwise valid automation brittle.
Would it be acceptable to issue a warning and treat an empty list as None instead, to preserve robustness? This would align with Matplotlib’s general philosophy of being tolerant and user-friendly toward benign input while still informing users of the preferred approach.

if not hatch_list:
    _api.warn_external(
        "'hatch' was an empty sequence; treating as no hatch. "
        "Use None explicitly to suppress this warning."
    )
    hatches = itertools.cycle([None])

I would rather argument, that it's likely an error in the programmatic code if it returns an empty list. I don't see a practical case in which one would naturally end up with an empty list if one has a finite set of groups and want to generate hatches. config.get("hatch", []) seems contrieved. Why would one want to write this instead of config.get("hatch") which will work correctly.

However, in practice, empty sequences can occur naturally in data-driven workflows. For instance, configuration files often deserialize [] for optional arrays (e.g., JSON/YAML style templates), and plotting utilities may use defensive defaults like config.get("hatch", []) to avoid KeyError. Similarly, dynamically generating hatches from metadata — e.g. [meta.get("hatch") for meta in datasets] — can yield an empty list when all datasets omit that field.
In such cases, treating [] as “no hatch” (with a warning) keeps things robust and user-friendly for automated or programmatic pipelines, while still guiding users to prefer None explicitly.

@timhoffm Waiting for your response. What did you decide regarding this?

Thanks, @timhoffm — I appreciate your detailed perspective. I’d like to clarify why I still believe that gracefully handling an empty sequence (with a warning) can be beneficial in the long run, both pragmatically and philosophically.

1. Defensive and user-friendly design

Matplotlib’s strength has always been its tolerance toward benign irregularities. Users rely on it as a stable visualization backend even when inputs are indirectly produced — from templates, configs, or pipelines — not always hand-written by developers.

Treating [] as equivalent to None (with a warning) preserves this spirit of robustness and continuity. It avoids brittle failures in higher-level tools that integrate Matplotlib as a rendering engine, especially when such inputs originate from sources beyond direct user control.

2. Real-world automation and serialization

Even though empty lists may seem unlikely in manual usage, they appear quite often in automated systems:
YAML/JSON serialization — missing or optional fields frequently deserialize to empty arrays rather than None.
Dynamic workflows — templated plotting pipelines or report generators (e.g., Airflow, Prefect, or CI visualizations) often construct keyword dictionaries dynamically. When an aesthetic parameter is unused, it may remain as an empty list placeholder.

Interoperability layers — frameworks like seaborn, pandas, or holoviews may forward arguments programmatically, sometimes defaulting to empty sequences when certain aesthetics are unused.
These cases are not errors per se — they are side effects of flexible, data-driven design where “no hatch” may naturally translate to an empty sequence.

3. Design philosophy — protecting the fragile parts

From a design standpoint, the absence of current breakage does not mean the absence of potential breakage.
If a construct can occur naturally in evolving ecosystems, it’s prudent to make the library resilient to it — especially when doing so is low-risk and consistent with existing semantics (None already means “no hatch”).
Designing defensively means protecting things that could break, even without hard proof that they already do. In software ecosystems, “possible” often becomes “inevitable” over time as integration layers grow.

4. Minimal cost, maximal stability

Issuing a warning — rather than raising — strikes a balanced compromise:
It informs users of the preferred canonical input (None).
It preserves existing behavior for programmatic systems that may unintentionally produce [].
It avoids introducing regressions in automated pipelines where errors may not be easy to trace back to Matplotlib.

So, while I agree that hatch=[] might not be common in hand-written code, its graceful handling can future-proof Matplotlib against subtle integration issues in complex or automated visualization systems — where inputs are often constructed indirectly rather than typed explicitly.

In essence, this isn’t about accommodating an artificial case — it’s about maintaining the robustness and user-centered flexibility that have always defined Matplotlib’s design philosophy.

I’d like to open a separate issue to discuss this more broadly, since the handling of empty sequences (like hatch=[]) may have implications beyond this specific function.

This could be an opportunity to evaluate whether Matplotlib should adopt a consistent, system-wide approach toward benign empty inputs — for example, treating them as “no-op” equivalents with a warning, rather than raising outright.

Such a discussion could help clarify the library’s general stance on defensive input handling versus strict validation, especially in the context of data-driven or programmatic pipelines that interface with Matplotlib.

Personally, as a user, it feels more natural and intuitive to assign hatch = [], since it allows me to dynamically add or remove patterns later

I recognize you are trying to make your point. However, you are not responding to my points in #30726 (comment). In particular, please stop posting AI-generated content. A generic AI argument falls short of considering the nuances and context of API design here. I am not spending time on rebutting AI gibberish. (I'm sorry if my AI assumption is wrong, but the text feels very AI-generated and scanners say with 99% likelihood it is.)

These principles found my decision:

• In the face of ambiguity, refuse the temptation to guess.
• Errors should never pass silently.
• Consistency - compare stackplot(..., hatch)
• If in doubt, keep the API minimal. - It's much simpler to later extend the API than to narrow it.

I just wanted to point out a small consistency angle that might be worth considering. If None is accepted to mean “no hatch,” then treating an empty list [] the same way actually keeps the API simple rather than expanding it — both essentially express “no pattern.”

For example:

config = {"color": ["red", "blue"], "hatch": []}
ax.bar(x, y, **config)

In a lot of configuration-driven setups (like JSON or YAML), optional arrays often deserialize as empty lists by default instead of None. Handling [] like None would make the behavior more predictable and tolerant in those cases, without changing the meaning or adding any new semantics.

This isn’t about guessing what the user wants — it’s more about keeping the two representations of “no hatch” consistent in data-driven workflows, where either form might appear naturally.

For instance, in dynamic plotting code, users might deliberately pass [] when they’re building visual attributes incrementally or conditionally:

hatches = []
if use_patterns:
    hatches.append('//')
ax.bar(x, y, hatch=hatches)

In this kind of logic, hatches starts as an empty list by design — it’s not an error or a missing value, just a placeholder that may or may not be populated later depending on conditions. Passing [] deliberately keeps the code clean and avoids special-case checks like:

ax.bar(x, y, hatch=None if not hatches else hatches)

So, supporting [] as equivalent to None helps in situations where users or frameworks construct arguments dynamically, keeping code simpler and more consistent without altering semantics.

There can be - IMHO rare - cases where this is convenient. But that’s not enough reason for me to be more permissive, given it potentially hides unintended behavior and is not in line with how stackplot operates (our most prominent existing multi-dataset plotting function).

I wield my decision authority as the project API lead here to end the discussion so that we can move forward.

It is possible to reconsider later, and broaden the API if strong user becomes apparent. That would be a global API decision and affect stackplot and possibly Collections as well.

Thanks, Tim — I appreciate the clear decision and your time in walking through the reasoning. Understood on keeping the API strict for now and prioritizing consistency with stackplot. I won’t push the point further, and I’ll make the required changes to the code soon.

can you condense the whitespace please?

Also, why not just follow the pattern in hist and allow a string (since we're allowing 1d list) and therefore simplify the error checking - basically bar handles the hatch validation instead of grouped bar.

https://github.com/matplotlib/matplotlib/blob/dedfe9be48ad82cade86766ef89410844ff09b31/lib/matplotlib/axes/_axes.py#L7560C8-L7560C76

When hatch is given as a single string (e.g. "//"), we raise a ValueError. This prevents Matplotlib from incorrectly iterating over individual characters ('/', '/') instead of treating the hatch as a single pattern.

@story645 @timhoffm

https://github.com/matplotlib/matplotlib/blob/dedfe9be48ad82cade86766ef89410844ff09b31/lib/matplotlib/axes/_axes.py#L7560C8-L7560C76 --->>>>>> the implementation cycles hatch patterns per patch, which breaks grouped bar semantics because each dataset generates multiple patches. This causes the hatch sequence to repeat incorrectly within the same dataset.
I am wondering if we need to replace the patch-level cycling with a dataset-level normalization instead? Specifically:
determine the number of datasets (num_datasets = len(heights)),
normalize hatch to one pattern per dataset, and
apply that hatch consistently to all patches for that dataset.
This would align hatch behavior with how color and label are already broadcast in grouped_bar, and it also resolves the test failures caused by per-patch cycling.

Specifically:
determine the number of datasets (num_datasets = len(heights)),
normalize hatch to one pattern per dataset, and
apply that hatch consistently to all patches for that dataset.

Sounds good to me, I think would also then allow for easier expansion into nesting (hatch per patch per dataset) if we wanted to go that direction.

[MNT]: Discussion : Normalize hatch patterns per dataset instead of per patch in grouped_bar #30789

I’ve created a new issue to address the hatch-normalization behavior in grouped_bar (i.e., switching from per-patch hatch cycling to per-dataset hatch assignment). This allows us to track that behavioral change separately from PR #30726, which is already large and focused on adding hatch support. Splitting this out avoids scope creep, keeps the current PR reviewable, and ensures the semantic change to hatch handling receives dedicated discussion and review.

@timhoffm @story645

@ilakkmanoharan I closed that issue b/c that behavioral discussion is necessary in this PR to move this PR forward - it's not scope creep b/c it's inherent to how you're handling the hatch argument and which errors to throw. If the current behavior of grouped hatch is one color per dataset, than the behavior of hatch should also be one color per dataset. This is also consistent with stackplot. Also, that's the behavior you've documented:

Until you get better intuition for what would make a good issue, I strongly recommend you ask maintainers if a discussion warrants a stand alone issue before opening a new one.