On 16/08/2020 9:41 pm, Guido van Rossum wrote:
On Sun, Aug 16, 2020 at 12:37 PM Jean Abou Samra <jean@abou-samra.fr <mailto:jean@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-c...>
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@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/NKM4QQNL... Code of Conduct: http://python.org/psf/codeofconduct/