On Sat, 9 Jan 2021 at 13:53, Antoine Pitrou <antoine@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.