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.
But it's nor normative. However...
>>> 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 :)
Certainly I see it as +1 for having the semantics independently verified.
[...]
> Guido van Rossum wrote:
>> On Fri, Apr 2, 2021 at 3:38 AM Mark Shannon mark@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?
I was surprised to find this phrase in the PEP, so I suspect that it was just a mistake when I wrote that section of the PEP. I can't find a similar restriction in PEP 622 (the original pattern matching PEP).