-
Notifications
You must be signed in to change notification settings - Fork 64
Consider 'PATTERN as name' instead of 'name := PATTERN' #140
Comments
I agree that this is sensible enough to warrant consideration and a brief discussion. Moreover, the Concerning the reasons that Jean Abou Samra mentions: The walrus Pattern matching is close to There is another aspect, though, that I like about this: using |
Especially with multiple walrus operators in a single line one easily gets cross-eyed, compare:
vs
Would that mean though that we'd either get the walrus operator or |
Another point to consider: The So is the walrus pattern more like
We should have one or the other, not both. (To see for yourself, try a more complex, complete example both ways.) |
Yes, at least as I understand it. The rationale for using |
but I agree that |
This is an interesting point (highlights from me) and I fully agree. |
Using
would just read too much like a context manager to be easily teachable (in my personal opinion ). |
Since
instead of
The advantage is again much like with
the current syntax looks a bit like the last pattern is somehow special because it can have a guard. This is probably somewhat related to #130 about non-backtracking behavior of guards that suprised me because my first language (Mathematica) does backtrack guards. |
I don't want to open up the floor right now for However, I would be happy to rearrange the grammar rules so you can write the following:
but the following would be a syntax error:
That way we can change our mind in the future. |
Since Yet another benefit of allowing
I dislike 1. because when there are lots of cases the definition of |
Yes, that’s the idea. Disallow it now (syntactically) so we can add it in the future. ——-
Note that case (4) is different from the others, it accepts any Mapping, vs. just dict and subclasses for the others. Regarding (1) vs. the rest, that’s going to be different in different cases, so it’s good to have options here. And (2) vs. (3) is pretty much esthetics, it’s hard to argue about. Also we already had that discussion above and came out in favor of “as”, so no need to repeat this. |
Note to self: Add Jean Abou Samra to Acks in PEP. |
Thanks. @gvanrossum I guess @SaschaSchlemmer meant that, in a future where guards would be allowed for subpatterns (for what could be called "guarded patterns"), we could have "PAT1, PAT2 if COND" mean "(PAT1, PAT2) if COND" so the current behavior would be kept without a need for syntax restrictions today. In other words, the comma (as well as "as" and "|") would bind tighter than "if". I think it makes sense as global guards are going to be much more frequent (and they are the only ones allowed by the current proposal). Also, it'll be easier to detect your mistake in case you understand it the wrong way. Take PAT1 | PAT2 if COND. Let's assume it means PAT1 | (PAT2 if COND). You could write case int(x) | Fraction() as x if x > 0: and because you wrongly think it means "(int(x) | Fraction() as x) if x > 0", you get negative integers matched, leading to weird failures. Now assume "PAT1 | PAT2 if COND" means "(PAT1 | PAT2) if COND" but you think of it the other way. You're going to write, for example, case int(x) | Fraction() as x if x.denominator == 1: and the problem will soon become obvious because int objects have no attribute 'denominator'. However, I'm not sure that guarded patterns are terrible with 'if' as a keyword. With the current draft, you can read 'case ... if ...' which is natural, but as long as 'PAT if COND' is parenthesized, it very much looks like the start of a ternary operator A if C else B, whereas it has quite a different meaning. To summarize:
|
I don't think that's workable, though. It would mean that: match ...:
case P1 if C1, P2 if C2: ... ...is equivalent to... match ...:
case ((P1 if C1), P2) if C2: ... ...which I think everyone can agree is unintuitive. Either way, this idea is probably off-topic for this issue. |
Oh! Indeed, now I understand why Guido was proposing to restrict the syntax. I'm sorry for having cluttered this issue with pointless text. |
Note that all comments since this one are irrelevant to the topic at hand (the discussion wandered to nested guards). |
Can we make a decision on this? I now favor Unlike I believe that going left-to-right also clears up readability in these unparenthesized cases: it's much clearer to me what "as-patterns"? I've gotten used to calling |
Agreed. I am also in favour of |
+1 If we're in agreement here I see no need to ask the SC (they can always ask that we change it back if they don't like it). Could one of you submit a separate PR that changes this in the PEPs? (Or one PR per PEP, at your choosing -- coordinate here without me.) |
(Also, this comment provides useful motivation for the rationale: #140 (comment)) |
I am updating PEP 635. |
This has been addressed for PEP 634 and PEP 635 on master; and for PEP 636 in python/peps#1658, so labeling as "fully pepped". |
Towards the end of this python-dev message, Jean Abou Samra lists some reasons why
PATTERN as name
would be more readable thanname := PATTERN
. I don't recall that we considered this before, but right now the two look about equal (i.e., I can't think of a good reason whyas
wouldn't work), so we should at least think about it.The text was updated successfully, but these errors were encountered: