On Sun, 10 Jan 2021, 2:55 am Paul Moore, <p.f.mo...@gmail.com> wrote:
> On Sat, 9 Jan 2021 at 14:54, Nick Coghlan <ncogh...@gmail.com> wrote:
>
> [...]
> > And I've already said I'd be fine with making the colon mandatory if the
> SC share that view.
>
> So the response to my comment that omitting the colon makes it hard to
> see that it's a dictionary unpacking is either "don't use that form if
> you don't like it" (which as we all know doesn't account for the
> problem of dealing with other people's code) or "the SC can make the
> colon mandatory" which seems to me to be extending the SC's role to
> designing the syntax rather than just approving the proposal. And
> means that the PEP we're debating might not be what gets accepted.
> Which isn't how I understood the process to work, but OK.
>
It's the same process any PEP goes through: comments from the PEP delegate
carry more weight than general review comments, as ignoring them risks
getting the PEP rejected.
>
The SC haven't provided any feedback on the submitted version of 642 yet,
so I don't know at this point if they share the concern that allowing
omitting the key/value separating colon to be omitted pushes mapping &
instance attribute patterns too close to looking like a variation on set
syntax instead of mapping syntax.
I do accept that it's a legitimate concern, it's just also a feature that's
easy to drop if the SC agrees it is problematic.
> And if the colon is mandatory, the syntax is {"text": as message,
> "color": as c}. Which is essentially the same as PEP 634 with an
> additional "as". Which basically makes this a somewhat disguised
> version of "add a marker to indicate the variable to be bound".
It isn't disguised at all, as I state it in the PEP's Design Discussion
section:
"""... instead requiring that all uses of bare simple names for anything
other than a variable lookup be qualified by a preceding sigil or keyword"""
(from
https://www.python.org/dev/peps/pep-0642/#requiring-explicit-qualification-of-simple-names-in-match-patterns
)
Meh.
> We've been down this route, some people want bindings to be explicitly
> marked, other people don't. I don't feel compelled to have explicit
> markers, I like the "match pattern looks like what's being matched"
> feature of PEP 634,
PEP 634 doesn't have that feature for class patterns in general, only for
classes like data classes, where the constructor signature is carefully
aligned with the match arguments.
For positional args, PEP 642 would also align in those carefully
constructed cases, so it's only the new syntax for attribute matching where
things differ.
For mapping patterns, I think you've made a reasonable case that the colon
should be required even when unconditionally binding names, so it wouldn't
surprise me at all if the shorthand to omit them gets rejected by the SC
(or at least moved to the "Deferred Ideas" section).
> What other syntax do we have that binds to the right without "as"?
> Allowing it at all is only as old as with statements, but that's still more
> precedence than ":" and "=" have for being used that way.
>
> None at the moment, but that's not my point. My point is that patterns
> are more like expressions than statements, and all current uses of
> "as" for binding are in statements. Expressions typically use
> punctuation rather than keywords, so there's no compelling argument
> that the syntax for "binding the RHS" *in expressions* has to be "as".
>
But PEP 634 uses "PTRN as NAME" as well.
The only difference in this regard between the two PEPs is that 634 allows
"_ as NAME" to be shortened to just "NAME" (omitting both the pattern and
the keyword), while 642 only allows "__ as NAME" to be shortened to "as
NAME" (omitting only the pattern).
You say "we use as in statements, so let's re-use that", I say "we use
> punctuation in expressions, and a keyword looks clumsy and verbose". I
> don't believe that point has ever been addressed directly, which is
> why I get frustrated that arguments about "as" seem to be getting
> redirected into arguments about binding to the right all the time.
>
I didn't realise it was an argument you were trying to make.
Cheers,
Nick.
> >
>
_______________________________________________
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/4YGNYB44PXEHD3WFX6DKQI3LHOAYUC5S/
Code of Conduct: http://python.org/psf/codeofconduct/
