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.
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". 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, and don't have a huge difficulty understanding
what's bound and what's matched in the sort of real-world cases that
have been presented. The nearest to a problem I've seen is "case
CONSTANT", which I acknowledge is a potential bug magnet, but I think
the "solution" proposed by PEP 642 is far worse than the problem.
> 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".
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.
> 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.
So based on that comment, PEP 642 isn't a proposal so much as a
selection of options the SC can pick between. And attempts like this
to discuss specifics of the proposal are hard to have, because "well,
the SC can drop that bit if they don't like it" is always an option. I
don't like that, and I'm not sure it's the right way to use the PEP
process. I'm inclined to suggest the SC should reject the proposal
simply because it leaves too much undecided, and doesn't take a firm
position ;-)
But whatever. To restate my position (which hasn't changed much) - I
like the idea of pattern matching in Python. PEP 634 seems like a
"natural" syntax to me, even though it's somewhat "do what I mean" in
terms of the exact details (in other words, I find it a good practical
approach even if it frustrates the rulebook lawyer in me). I dislike
PEP 642, although I can't honestly put my finger on why - mainly, it
seems like it prioritises rules (ease of implementation, keeping the
spec concise) over usability. I don't think pattern matching is
important enough to accept the usability compromises that I feel PEP
642 requires, but I *do* think it's sufficiently important to mean
that I'm comfortable accepting the edge cases (specification
compromises) in PEP 634. If PEP 642 were accepted, I'd use pattern
matching a *lot* less than if PEP 634 were accepted (and I'd argue
against its use more often on projects I contribute to). I'm glad I'm
not on the SC and having to make this decision.
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/3RJG5FDUJVV5GCNPXTCWQQVUQXICYDWB/
Code of Conduct: http://python.org/psf/codeofconduct/
