On Thu, Apr 1, 2021 at 8:01 PM Terry Reedy <tjre...@udel.edu> wrote: > On 4/1/2021 9:38 PM, Guido van Rossum wrote: > > > On Thu, Apr 1, 2021 at 2:18 PM Mark Shannon <m...@hotpy.org > > <mailto:m...@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-change-the-world/>
_______________________________________________ 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/ABNFOYT3A6LCWXE2MUSF6PNTUQRIZ4PV/ Code of Conduct: http://python.org/psf/codeofconduct/
