On Thu, Apr 1, 2021 at 8:01 PM Terry Reedy
On 4/1/2021 9:38 PM, Guido van Rossum wrote:
On Thu, Apr 1, 2021 at 2:18 PM Mark Shannon 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. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...