On Wed, Jul 29, 2020 at 4:34 PM Nick Coghlan <ncogh...@gmail.com> wrote:
> I'm still only intermittently keeping up on python-dev, but my main > concern with the first iteration remains in this version, which is that it > doesn't even *mention* that the proposed name binding syntax inherently > conflicts with the existing assignment statement lvalue syntax in two areas: > I don't see why the PEP would be required to mention this. You make it sound like it's a bad thing (a "conflict"), whereas the PEP authors' position is that it is irrelevant. > * dotted names (binds an attribute in assignment, looks up a constraint > value in a match case) > * underscore targets (binds in assignment, wildcard match without binding > in a match case) > > The latter could potentially be made internally consistent in the future > by redefining "_" and "__" as soft keywords that don't get bound via normal > assignment statements either (requiring that they be set via namespace dict > modification instead for use cases like il8n). > https://www.python.org/dev/peps/pep-0622/#use-some-other-token-as-wildcard > presents a reasonable rationale for the usage, so it's only flaw is failing > to mention the inconsistency. > That solution is outside the scope of the PEP -- it would be a big backward incompatibility with little payoff. Your repeated mention of consistency makes me want to quote PEP 8 (quoting Emerson, though I didn't even know who that was when I put it in my style guide :-): "A foolish consistency is the hobgoblin of little minds." > The former syntactic conflict presents a bigger problem, though, as it > means that we'd be irrevocably committed to having two different lvalue > syntaxes for the rest of Python's future as a language. > Things become much less "conflict-y" if you stop seeing patterns as lvalues. They just aren't, and any argument based on the idea that they are is inherently flawed. (Also note that the concept of lvalue isn't even defined in Python. There are a variety of assignment targets with different syntactic constraints depending on context, and several other syntactic constructs that bind names.) > > https://www.python.org/dev/peps/pep-0622/#alternatives-for-constant-value-pattern > is nominally about this problem, but it doesn't even *mention* the single > biggest benefit of putting a common prefix on value constraints: it leaves > the door open to unifying the lvalue syntax again in the future by keeping > the proposed match case syntax a strict superset of the existing assignment > target syntax, rather than partially conflicting with it. > That's because the PEP authors disagree with you that this goal is worthy of pursuit, and hence we don't see care about this benefit at all. > More incidentally, the latest write-up also leaves out "?" as a suggested > constraint value prefix, when that's the single character prefix that best > implies the question "Does the runtime value at this position equal the > result of this value constraint expression?" without having any other > existing semantic implications in Python. > In the discussion pretty much all non-alphanumeric ASCII characters have been proposed by various people as sigils to mark either capture patterns or value patterns. We didn't think it was necessary to enumerate all proposed characters and write up reasons why we reject them, since the reasons for rejection are pretty much always the same -- it looks strange, and there's no need for sigils at all. Honestly, it doesn't help the case for `?` that it's been proposed as a mark for both capture patterns and value patterns (by different people, obviously :-). > Cheers, > Nick. > > P.S. I feel I should mention that the other reason I like "?" as a > potential prefix for value constraints is that if we require it for all > value constraint expressions (both literals and name lookups) I believe it > could offer a way to unblock the None-aware expressions PEP by reframing > that PEP as a shorthand for particular case matches. > > None coalescence ("a ?? b") for example: > > match a: > case ?None: > _expr_result = b > case _match: > _expr_result = _match > > Or a None-severing attribute lookup ("a?.b"): > > _match_expr = a > match _match_expr: > case ?None: > _expr_result = _match_expr > case _match: > _expr_result = _match.b > > Since these operations would be defined in terms of *equality* (as per PEP > 622), rather than identity, it would also allow other sentinels to benefit > from the None-aware shorthand by defining themselves as being equal to None. > This sounds like a huge stretch. Trying to forge a connection between two separate uses of the same character sounds like arguing that the `*` in `a * b` and the `*` in `*args` are really the same operator. I am actually rather in favor of PEP 505, but that doesn't make any difference for how I see marking value patterns in PEP 622. --Guido > On Thu., 9 Jul. 2020, 1:07 am Guido van Rossum, <gu...@python.org> wrote: > >> Today I’m happy (and a little trepidatious) to announce the next >> version of PEP 622, Pattern Matching. [...] >> > -- --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/ZO7XZNWQQWPJMY7CZND6YQC5TI3NCYL7/ Code of Conduct: http://python.org/psf/codeofconduct/
