I couldn't find any information on whether this was considered and rejected during the pattern matching PEP, so apologies if this is already settled.

I've just encountered this use-case repeatedly so I figured it was time to make a thread on this.

Basically, I'd like to be able to designate a pattern like this:

match val:
    case [*str()]:
        ...

Where 'val' will match an iterable containing zero or more strings.

This should also work with more complex sub-patterns, like:

match humans:
    case [
        *{
            'name': str(),
            'age': int(),
        }
    ]:
        ...

Where 'humans' should match an iterable of zero or more mappings where each mapping contains the keys 'name' and 'age' (and where the value for name is a string and the value for age is an int).

Sure, you can use the sentinel clause to do it, but imagine you've got a case statement where you're using 10 different variadic sub-patterns. You'd have an unbearably long string of:

case {PATTERN_GOES_HERE} if (
    all(isinstance(val1, some_type1) for val1 in sub_pattern1)
    and all(isinstance(val2, some_type2) for val2 in sub_pattern2)
    and ...
)

And that's assuming simple variadics like my first example above, and not my second example!

This incidentally destroys the gain in legibility of using a pattern in the first place.

Is anyone aware of a reason variadic patterns weren't included in the PEP? Was it an oversight, or was it deemed too niche to include in the original spec? Or were there implementation-related reasons? Something else?

It just seems like it would make match statements way more powerful for data shape validation, which is one of the primary use-cases that the tutorial PEP showed off.

Cheers