On 16/08/2020 9:41 pm, Guido van Rossum wrote:
On Sun, Aug 16, 2020 at 12:37 PM Jean Abou Samra <j...@abou-samra.fr
<mailto:j...@abou-samra.fr>> wrote:
Hi there,
As a poor user, I am extremely excited about the possibilities PEP
622 (structural pattern matching) opens. I'd like to ask a few
questions.
I hope these were not already answered in other threads, which it is
hard to follow given the amounts of information.
Most of the threads can hardly be considered information -- at best it's
debate, arguments and opinions. :-)
First, I'd like to know wether walrus patterns are encouraged as an
expressive way to explain the code in addition to comments, for example:
match number:
case exact := numbers.Rational():
...
case inexact:
...
Here we rename number depending on the case clause that was taken.
Would this be considered good practice? Maybe it'd be worth
codifying in PEP 8 if PEP 622 is accepted?
I think we should wait a while to see what style develops before
recommending specifics. Right now I'm not excited about it, mostly
because the first case is a lot longer. Assuming the code blocks in the
cases aren't very long, it doesn't seem hard to keep the context ("is
the number exact or inexact here?") in mind without using the different
variable names.
A nit: how is the keywords module going to integrate soft keywords?
Perhaps not at all?
Already taken care of -- it has a separate list `softkwlist` (currently
empty) and corresponding function `issoftkeyword`. If any soft keywords
appear in the grammar the code generation process will update keyword.py.
Also, I see potential for a caveat:
match number:
case int: # missing parentheses!
...
case float:
...
case Fraction:
...
In this case, if I understand the specification correctly, the first
case will always match, right? Maybe the interpreter could throw a
SyntaxWarning when a bare capture pattern (without a guard) is used
as a pattern in any case clause other than the last one? As far as I
understand, this could possibly prevent many of the mistakes in
load/store that people have been rightfully complaining about so
far. It's merely a stronger measure than letting static checkers do
the work (since we don't all use these tools).
The reference implementation in fact does issue a SyntaxWarning for this
case.
Shouldn't that detail be in the PEP?
Finally, was as-based syntax considered as an alternative to walrus
patterns, that is, PATTERN as NAME instead of NAME := PATTERN, as we
have in the try statement? Given the extensive discussion, I guess
it might have been rejected, so it could deserve a place under
"Rejected ideas" -- this holds for all the above too, which I'm
sorry about if it's dumb.
I don't recall it was discussed. A very early draft (that wasn't
published) used `as` instead of `case`, and that draft used `:=` for
this purpose. It's always made sense to use that, so I've never
considered `as`. Do you think there are situations where `as` has a
clear advantage over `:=`?
Anyway, unless someone digs up an actual thread where this was discussed
I think it's not worth adding to Rejected ideas (we can't possibly
review the entire design space).
--
--Guido van Rossum (python.org/~guido <http://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/NKM4QQNLKOH5J2DNS55LBKFGG2H2JGLY/
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/UIYT3LCWYCFYYD27NQ6G3K4ZDRUNF2CP/
Code of Conduct: http://python.org/psf/codeofconduct/
