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
On Sun, Aug 16, 2020 at 12:37 PM Jean Abou Samra <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.
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?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...>
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/
On Mon, Aug 17, 2020 at 3:37 AM Mark Shannon <mark@hotpy.org> wrote:
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: 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?
Good point. I have added a note about this in the section on static checkers, under "Note about constants": https://github.com/python/peps/commit/6a7d6b831f9af7db651269231c77037aff6bad... (I should mention that the PEP authors are also grateful for your observation about what users expect for `case True`, and we are now discussing this in our issue tracker at https://github.com/gvanrossum/patma/issues/139. We're also discussing Jean's point about `as` vs. `:=` in issue 140.) -- --Guido van Rossum (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...>
Hi, Thanks for your reply!
Le 16 août 2020 à 22:41, Guido van Rossum <guido@python.org> a écrit :
On Sun, Aug 16, 2020 at 12:37 PM Jean Abou Samra <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. :-)
You're entirely right.
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.
I recognise that my example was somehow too trivial; it would likely look more natural when rewriting visitors, where you could end up with a lot of code in each case clause. For instance, if I had to rewrite https://github.com/sympy/sympy/blob/c3087c883be02ad228820ff714ad6eb9af1ad868... I may write: case num := Num(), etc. (By the way, if you read sympy_parser.py in the same directory, it's full of examples where pattern matching would be useful.) I also noticed this in the PEP, under "Capture patterns": match greeting: case "": print("Hello!") case name: print(f"Hi {name}!") Anyway, I agree that the best way forward is to wait and see what usage patterns develop (no pun intended).
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.
My bad, I should have checked out the dev documentation since the PEG parser is a novelty...
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.
Good! (Sorry, I couldn't check that as mybinder.org currently seems unavailable... :-( ).
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 `:=`?
Let's see: it probably avoids some uglinesses that occur with the use of = in class patterns. case Expr(value=(add := BinOp(op=Add()))): vs. case Expr(value=(BinOp(op=Add()) as add)) There is also case Line(start := Point(x, y), end): which might be confused with case Line(start=Point(x, y), end): However, the main reason why I was asking is that 'as' parallels well with the current context that is closest to pattern matching, namely the try statement. The walrus parallels with assignment expressions, so this is in fact a story of wether patterns should look more like expressions or the LHS of an assignment, as I see it. The walrus highlights the structure that you're trying to fit in: "This is an Expr, having as a value an addition, which looks like ...". By contrast, having the name after the pattern makes you think like the interpreter: "Try to fit this into BinOp(op=Add()), and if that succeds, put it in 'add'." Both are defendable. I think the latter would be a little easier to teach, so I'd encourage considering it. Best, Jean Abou Samra
On Mon, Aug 17, 2020 at 10:04 AM Jean Abou Samra <jean@abou-samra.fr> wrote: [Jean]
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.
[Guido]
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 `:=`?
[Jean]
Let's see: it probably avoids some uglinesses that occur with the use of = in class patterns.
case Expr(value=(add := BinOp(op=Add()))): vs. case Expr(value=(BinOp(op=Add()) as add))
There is also case Line(start := Point(x, y), end): which might be confused with case Line(start=Point(x, y), end):
However, the main reason why I was asking is that 'as' parallels well with the current context that is closest to pattern matching, namely the try statement. The walrus parallels with assignment expressions, so this is in fact a story of wether patterns should look more like expressions or the LHS of an assignment, as I see it.
The walrus highlights the structure that you're trying to fit in: "This is an Expr, having as a value an addition, which looks like ...". By contrast, having the name after the pattern makes you think like the interpreter: "Try to fit this into BinOp(op=Add()), and if that succeds, put it in 'add'." Both are defendable. I think the latter would be a little easier to teach, so I'd encourage considering it.
Okay, I opened an issue in the PEP team's internal tracker about this: https://github.com/gvanrossum/patma/issues/140 -- --Guido van Rossum (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...>
On 16/08/2020 8:23 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.
OOI, what possibilities? I'm genuinely interested know what problems PEP 622 would solve for you.
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 -- 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/2HDCJYUL... Code of Conduct: http://python.org/psf/codeofconduct/
participants (3)
-
Guido van Rossum -
Jean Abou Samra -
Mark Shannon