![](https://secure.gravatar.com/avatar/e6a87d3f508d8742129e4bdf025b47d3.jpg?s=120&d=mm&r=g)
Heya Chris. Not sure where you're getting the idea that pattern matching is meant to be only for attributes or values and not types. Matching on type is one of the main examples the tutorial PEP showed off (see the example where an event is matched against several different types such as Click, KeyPress, or Quit). Saying it is categorically bad to match on type seems to me an overly dogmatic statement, which might certainly be true in the kind of code you write in your area of work, but in general there are more use-cases for isinstance-like behaviour than I could possibly name. Just to mention the first example that comes to mind, the pandas DataFrame constructor is capable of accepting many different orientations of data to construct a DataFrame from, (row-wise as a list of tuples with 'columns=' passed as an argument, record-wise as a list of dicts, etc.). It also needs to be able to infer the type for each Series from the data passed. While for pandas in particular a pure-python implementation would never be deemed sufficiently performant, you can imagine similar but domain-specific lightweight tabular data classes needing to do the same thing and opting using the type matching capabilities of the match statement for it (if it could handle variadic patterns). My use-cases have usually been in data engineering, so for example writing integration tests that validate that a given API returns payloads with the correct shema (including types), or validating that the front-end designers making internal API calls within a webapp are actually passing valid json payloads (both structure and type) in a single compact statement. I realize there are more heavyweight alternatives like, for instance, Pydantic models, but there are environments where people don't have permissions to install third-party libraries, or where compliance requirements prevent it, or where the scope of the work is so small that it might feel like overkill to reach for something with a potentially steep learning curve. Regardless, given that the match statement already supports matching on type as a first-class operation, I think this particular point is somewhat off-topic and would have belonged when structural pattern-matching was first being discussed. My suggestion is to allow variable-length patterns (and sub-patterns). The fact that python patterns have the ability to match on type isn't really relevant, because that is existing functionality. Cheers, Matt On Wed, Sep 14, 2022 at 3:43 PM Christopher Barker <pythonchb@gmail.com> wrote:
On Tue, Sep 13, 2022 at 8:44 AM Matt del Valle <matthewgdv@gmail.com> wrote:and bind them
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).
I haven't yet used pattern matching, but even without that context, this strikes me as mathicn on type, rather than value.
which doesn't, in my mind, belong in code that's going to run during run time.
I wouldn't write:
if obj and all( isinstance(o, str) for o in obj): do_something
so why would I use it in pattern matching?
Granted, the distinction between type and value gets a bit messy in Python, but I"d think:
each mapping contains the keys 'name' and 'age'
would be value, but:
(and where the value for name is a string and the value for age is an int).
would be type.
I do see that kind of checking to be useful, for, e.g. unpacking JSON data, but I'm not sure this is where it belongs -- that kind of checking, to me, is validation of the JSON, defining the structure belongs in a different place, in a different way.
I would be interested in hearing about the use cases you have in mind, and where that fits into the whole type vs value checking continuum.
-CHB
-- Christopher Barker, PhD (Chris)
Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython