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 <python...@gmail.com>
wrote:
> On Tue, Sep 13, 2022 at 8:44 AM Matt del Valle <matthew...@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
>
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/IKDK2FZPNWMP3K7A4XFMTOAOASYXRPZB/
Code of Conduct: http://python.org/psf/codeofconduct/
