On Sun, 10 Jan 2021, 12:22 am Paul Moore, <p.f.mo...@gmail.com> wrote:
> On Sat, 9 Jan 2021 at 13:53, Antoine Pitrou <anto...@python.org> wrote:
>
> > So, opposing Nick's proposal on the basis that it "looks like a set" is
> > just like opposing set literals on the basis they they "look like a
> > dict".
>
> That's not what I was doing (I can't comment on what Paul S intended,
> though). My position is that the lack of a colon makes this not look
> like a dictionary destructuring to me. The "as" keyword doesn't have
> the same feeling of describing the *form* of a data structure,
> possibly because structure in fundamental data types is more often
> indicated by punctuation than keywords.
>
And I've already said I'd be fine with making the colon mandatory if the SC
share that view.
> As a larger point, I'm saying that Nick's proposal has just as many of
> these "doesn't feel quite right" compromises as the original proposal
> (actually, *to me* it has far *more* of them, but there's a level of
> subjectivity here). As a result, I'm unmoved by the arguments that
> "it's pattern matching, but with a nicer syntax".
>
> The dictionary destructuring can act as an example. We know Nick's
> position:
>
> case {"text": message, "color": c}:
>
> 1. There's nothing (other than the fact that it's in a case clause) to
> indicate that message and c are assigned to.
> 2. It "binds to the right without using as", (as far as I can see,
> based on the premise that "as" is the only valid way of binding names
> where the name is on the right, which was asserted without any
> justification).
>
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.
> But the PEP 642 form:
>
> case {"text" as message, "color" as c}:
>
> is essentially identical except for using "as" rather than a colon. My
> view is:
>
> 1. Nowhere else in Python does "as" indicate a dictionary, and braces
> alone don't (because sets use them too).
> 2. It loses the "match looks like the input" aspect, while only
> gaining some sort of theoretical "as is how we bind to the right"
> property that's never been a design principle in Python before now.
> 3. It's entirely new syntax, where the PEP 634 form is similar to
> existing Python syntax for dictionaries, and to other languages'
> matching constructs.
>
> What I'm saying here is simply that looked at (relatively)
> objectively, there are similar numbers of debatable points on both
> sides of the argument.
>
Except that many of the PEP 642 ones are optional shorthand that the SC can
selectively reject or defer if they want to - for example, always requiring
the use of ":" in both mapping patterns and instance attribute patterns
would only increase verbosity, it wouldn't reduce expressivity.
PEP 634 is more constrained than that. For example, mapping keys have to be
restricted to just literals and attributes, because allowing bare names or
more complex expressions would make the pattern name bindings too hard to
pick out.
Cheers,
Nick.
> Paul
> _______________________________________________
> 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/CIFLROSUOK3TET2Q6LWVDEHH3C2DAIAL/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
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/SZHIT23BFSLIVRKZU3CNUTXS35ISJLBZ/
Code of Conduct: http://python.org/psf/codeofconduct/
