On 4/1/2021 9:38 PM, Guido van Rossum wrote:
> On Thu, Apr 1, 2021 at 2:18 PM Mark Shannon <mark@hotpy.org
> <mailto:mark@hotpy.org>> wrote:
> Almost all the changes come from requiring __match_args__ to be a tuple
> of unique strings.
The current posted PEP does not say 'unique' and I agree with Guido that
it should not.
(Of course, "the current PEP" is highly ambiguous in this context.)
Well, now I have egg on my face, because the current implementation does reject multiple occurrences of the same identifier in __match_args__. We generate an error like "TypeError: C() got multiple sub-patterns for attribute 'a'". However, I cannot find this uniqueness requirement in PEP 634, so I think it was a mistake to implement it.
Researching this led me to find another issue where PEP 634 and the implementation differ, but this time it's the other way around: PEP 634 says about types which accept a single positional subpattern (int(x), str(x) etc.) "for these types no keyword patterns are accepted." Mark's example `case int(real=0, imag=0):` makes me think this requirement is wrong and I would like to amend PEP 634 to strike this requirement. Fortunately, this is not what is implemented. E.g. `case int(1, real=1):` is accepted and works, as does `case int(real=0):`.
Calling out Brandt to get his opinion. And thanks to Mark for finding these!
> Ah, *unique* strings. Not sure I care about that. Explicitly checking
> for that seems extra work,
The current near-Python code does not have such a check.
Again, I'm not sure what "the current near-Python code" refers to. From context it seems you are referring to the pseudo code in Mark's PEP 653.
> and I don't see anything semantically suspect in allowing that.
If I understand the current pseudocode correctly, the effect of 's'
appearing twice in 'C.__match_args__ would be to possibly look up and
assign C.s to two different names in a case pattern.
I would not be surprised if someone someday tries to do this
intentionally. Except for the repeated lookup, it would be similar to a
= b = C.s. This might make sense if C.s is mutable. Or the repeated
lookups could yield different values.
Yes, and this could even be a valid backwards compatibility measure, if a class used to have two different attributes that would in practice never differ, the two attributes could be merged into one, and someone might have a pattern capturing both, positionally. That should keep working, and having a duplicate in __match_args__ seems a clean enough solution.