On Thu, Sep 15, 2022 at 4:57 AM Matt del Valle <matthewgdv@gmail.com> wrote:
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.
I don’t- I have the idea that Python itself is not really about Types. Honestly, it makes me nervous when supposedly “optional” type hints start making their way into built in parts of the language and standard idioms. 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).
I guess my feeling is that there are better ways to solve those kinds of problems in Python.
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.
I’m not so sure that matching on Python type is the way to do that — for example, you may have a collection of floats and ints — you have to look at values to do that right. And more often than not, the source is something like a CSV file, where it’s all a string type. Even unpacking JSON — JSON has a much less rich type system than Python — do properly determining what a JSON object is requires more than type checking. 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)
See above — simple type checking is likely to be inadequate— and I’m not sure validation is the right use case for pattern matching either. 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.
This is the key point — and you are quite right. I’ll let others comment on whether this extension to pattern matching makes sense — I haven’t really dig into it enough to have an opinion. -CHB
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
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/IKDK2F... Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython