Hi Brandt,

On 02/04/2021 8:41 pm, Brandt Bucher wrote:
Mark Shannon wrote:
On 02/04/2021 7:19 am, Brandt Bucher wrote:
I agree that self-matching classes should absolutely allow keyword matches. I 
had no idea the PEP forbade it.
PEP 634 allows it.

PEP 634 says:

For a number of built-in types (specified below), a single positional 
subpattern is accepted which will match the entire subject; for these types no 
keyword patterns are accepted.

(https://www.python.org/dev/peps/pep-0634/#class-patterns)

I was relying on the "reference" implementation, which is also in the PEP.

>>> match 0:
...     case int(imag=0):
...        print ("Experimentally, int supports keyword matching.")
...
Experimentally, int supports keyword matching.

I take this as +1 for having more precisely defined semantics for pattern matching :)


Most checks are cheap though.
Checking for duplicates in `__match_args__` can be done at class creation time, 
and checking for duplicates in the pattern can be done at compile time.

I assume the compile-time check only works for named keyword attributes. The 
current implementation already does this.

-1 on checking `__match_args__` anywhere other than the match block itself.

I'm curious, why?
It is much faster *and* gives better error messages to check `__match_args__` at class creation time.


Guido van Rossum wrote:
On Fri, Apr 2, 2021 at 3:38 AM Mark Shannon m...@hotpy.org wrote:
Are there are any use-cases?
The test-case `int(real=0+0j, imag=0-0j)` is contrived, but I'm struggling to 
come up with less contrived examples for any of float, list, dict, tuple, str.
There could be a subclass that adds an attribute. That's still contrived  
though.

I could see the case for something like `case defaultdict({"Spam": s}, 
default_factory=f)`. I certainly don't think it should be forbidden.

It is forbidden in the PEP, as written, correct?
OOI, have you changed your mind, or was that an oversight in the original?

Cheers,
Mark.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/R7ZIAAQNL2CN3K3M3DMR2IQNC6DLD7FF/
Code of Conduct: http://python.org/psf/codeofconduct/

Reply via email to