[Python-Dev] PEP 622 questions
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. 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? A nit: how is the keywords module going to integrate soft keywords? Perhaps not at all? 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). 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. Best regards, Jean Abou Samra ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/2HDCJYULPKEDLHLMQH563VYZTG47ST3N/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: PEP 622 questions
On Sun, Aug 16, 2020 at 12:37 PM Jean Abou Samra 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.
> 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)
*Pronouns: he/him **(why is my pronoun here?)*
[Python-Dev] Re: Critique of PEP 622 (Structural Pattern Matching)
Steven D'Aprano writes:
> Oh, I'm sorry, I based my comment on Chris' comment that Mark was
> repeating everyone else's arguments. My bad :-(
Mark can be tendentious. Some of his arguments in the main gist were
also made by others, but mostly they do seem to be reiterations of his
own pet peeves.
That said, I think Guido was unfair. Mark's pamphlet does provide a
lot of new data for us to consider, not so much in the main
"Critique", but rather in the "Analysis of the Standard Library"[1].
To me, the "queries" he came up with seem a fair representation of the
kinds of things that this proposal might improve in the stdlib. I
found that Mark's rewritings are generally pretty attractive even
though they seem unlikely to provide substantial decrease in LOC and
quite unlikely to be more performant. I like destructuring as a way
of "breaking out" attributes to local bindings. I think most of the
pattern matching versions are distinct improvements over both the
existing code and Mark's suggested alternatives, although pattern
matching is a "big change" and his alternatives have much smaller
footprints on the future of Python.
I would make a few points based on little expertise in pattern
matching ;-), my esthetic sense about destructuring, and Mark's
critique and analysis.
1. In the Critique Mark argues use of pattern matching is likely to
be infrequent because of the heavy use of duck typing in well-
written Python code. But I find pattern matching to be
complementary to duck-typing. To be a bit melodramatic, it's an
extension of duck-typing from "walks and quacks like a duck"
("dynamic duck-typing") to "has a bill like a duck" ("static
duck-typing" or perhaps "platypus mistyping").
2. In the Analysis Mark argues that idioms amenable to pattern
matching in existing stdlib code are quite rare (a couple of dozen
instances, and as I wrote above I think his query was reasonably
representative). While that certainly is a useful analysis, it
cannot account for the fact that pattern matching is a *paradigm*
that has not been available in Python in the past. *Availability
of a pleasant syntax for a new paradigm causes code to be designed
differently.* That is something that none of us can claim to be
able to quantify accurately, although the experience Guido and
others have with "async" may be relevant to guesstimating it.
3. Mark identifies a number of minor deficiencies in the existing
proposal, of which the attractive nuisance of "symbolic constants"
(the "case HTTP_OK" example) and the inability to use pattern
matching directly to populate object attributes in __init__
methods were most impressive to me. (I still like the PEP.)
I wonder if it would be possible to provide hooks for a useful
amount of pattern matching syntax while leaving open the
possibility of future semantic improvements as was done with
function annotations.
> I guess at some point I shall have to read the entire thread if I want
> to have an opinion on this feature.
Only if the SC refuses to approve the current draft! ;-)
[1]
https://github.com/markshannon/pep622-critique/blob/master/stdlib_examples.md
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/7OA6N45NZZ64HPLS6PFJ4DCN2LHULCEZ/
Code of Conduct: http://python.org/psf/codeofconduct/
