Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax
Hello,
[Re-routed back to python-dev.]
On Thu, 12 Nov 2020 20:04:57 +0100 Piotr Duda duda.piotr@gmail.com wrote:
[]
match foo: case ("foo", >val1): ... case ("bar", >val2): ...
I agree with that, though I would prefer using other symbol than > (? or $), one of reasons would by it would look better as "match all" target, other one that in future. it would allow extending syntax for simple guards like ?x < 100.
Question of "what to mark with sigils - terms-used-as-values or terms-used-for-capturing" is orthogonal to the question of "what to use as match-all symbol", though I understand the desire to repurpose the same symbol for both.
For a capturing sigil, "->", ">", ">>", "@", "?", "$" already were or can be proposed. The benefit of "->", ">", ">>" is that they're very intuitive. I'd also have preference for shorter one, because 2-chars are really verbose IMHO. OTOH, ">" has issue with parsing ambiguity unless separated by spaces ("Cls(kw1=>var)"). "$" is the worst choice IMHO, because intuitively (based on other languages - shell, etc.) it says "use the value of variable".
That said, those are 2nd-level choices. The current stage is to accept the fact that "mark capturing terms" is *very viable* alternative to "mark terms to use as values" (3rd choices - "use adhoc interpretation of non-orthogonal syntactic conventions" - being the worst). But people behind PEPs keep ignoring that choice - silently, or with minimal consideration/commentary.
On 2020-11-12 19:21, Paul Sokolovsky wrote:
Hello,
[Re-routed back to python-dev.]
On Thu, 12 Nov 2020 20:04:57 +0100 Piotr Duda duda.piotr@gmail.com wrote:
[]
match foo: case ("foo", >val1): ... case ("bar", >val2): ...
I agree with that, though I would prefer using other symbol than > (? or $), one of reasons would by it would look better as "match all" target, other one that in future. it would allow extending syntax for simple guards like ?x < 100.
Question of "what to mark with sigils - terms-used-as-values or terms-used-for-capturing" is orthogonal to the question of "what to use as match-all symbol", though I understand the desire to repurpose the same symbol for both.
For a capturing sigil, "->", ">", ">>", "@", "?", "$" already were or can be proposed. The benefit of "->", ">", ">>" is that they're very intuitive. I'd also have preference for shorter one, because 2-chars are really verbose IMHO. OTOH, ">" has issue with parsing ambiguity unless separated by spaces ("Cls(kw1=>var)"). "$" is the worst choice IMHO, because intuitively (based on other languages - shell, etc.) it says "use the value of variable".
I'd still want to list "as" as another possibility, the advantage being that it's already used for binding elsewhere.
That said, those are 2nd-level choices. The current stage is to accept the fact that "mark capturing terms" is *very viable* alternative to "mark terms to use as values" (3rd choices - "use adhoc interpretation of non-orthogonal syntactic conventions" - being the worst). But people behind PEPs keep ignoring that choice - silently, or with minimal consideration/commentary.
I have a meta-observation. Clearly there are too many cooks here. The same suggestions keep getting brought up. We will never converge on a design this way. At this point the only thing to do is to wait for the Steering Council. I am not going to argue about the merits of any more specific ideas -- everything has already been proposed and the PEP authors have come up with a design that carefully weighs a *lot* of different requirements. The SC has indicated that they feel it's too close to the election date to decide, but they will come up with a recommendation for the next SC (which will likely have a significant overlap with the current SC). I will wait for that.
Hello,
On Thu, 12 Nov 2020 12:51:19 -0800 Guido van Rossum guido@python.org wrote:
I have a meta-observation. Clearly there are too many cooks here. The same suggestions keep getting brought up. We will never converge on a design this way.
Right, it's not a Python decision unless it's forced thru like PEP572, aka the ":=" (https://lwn.net/Articles/757713/ , etc.). Can also remember the whole Python3 migration business (https://gregoryszorc.com/blog/2020/01/13/mercurial%27s-journey-to-and-reflec... , etc).
At this point the only thing to do is to wait for the Steering Council. I am not going to argue about the merits of any more specific ideas -- everything has already been proposed and the PEP authors have come up with a design that carefully weighs a *lot* of different requirements.
Right, PEP622, PEP634, PEP635, PEP636 are very well written and discuss many options thoroughly. The sentiment that many people on the list have is that they then make a particular choice (like a PEP has to do of course), while there're other very viable choices (and one proposed by PEP has glaring adhockery). So, maybe, just maybe, it's too early yet to shut on one option, and would be beneficial to keep considering other options open-mindedly (for the PEP authors first of all, as clearly, there won't a competing PEP proposal).
So, while we keep waiting for SC, we can remember the short history of the mentioned PEP572. At times of PEP622, ":=" was touted as something like enabler for the whole pattern matching business, as that's what allows to do things like: "case [1, y := (1, x), 2]".
The suddenly, PEP634 silently (well, without much ado) replaces it with the "as" keyword. So much for the great enabler. And now ":=" keeps sticking a square peg in a round hole of the language, with this:
(a, b) = (1, 2)
- possible, and this:
((a, b) := (1, 2))
- oopsing:
File "<stdin>", line 1 SyntaxError: cannot use assignment expressions with tuple
Current PEP634 offers the same level of the language consistency and generality, with random (but practical, if you believe the PEP authors) hacks sprinkled around instead.
On Thu, Nov 12, 2020 at 11:41 PM Paul Sokolovsky pmiscml@gmail.com wrote:
Hello,
On Thu, 12 Nov 2020 12:51:19 -0800 Guido van Rossum guido@python.org wrote:
I have a meta-observation. Clearly there are too many cooks here. The same suggestions keep getting brought up. We will never converge on a design this way.
Right, it's not a Python decision unless it's forced thru like PEP572, aka the ":=" (https://lwn.net/Articles/757713/ , etc.). Can also remember the whole Python3 migration business ( https://gregoryszorc.com/blog/2020/01/13/mercurial%27s-journey-to-and-reflec... , etc).
Please keep the conversation civil.
-Brett
On 13/11/20 9:19 am, MRAB wrote:
I'd still want to list "as" as another possibility, the advantage being that it's already used for binding elsewhere.
Only where it makes English grammatical sense, though, which it doesn't unless there's something on both sides.
Hello,
On Thu, 12 Nov 2020 20:19:13 +0000 MRAB python@mrabarnett.plus.com wrote:
[]
Question of "what to mark with sigils - terms-used-as-values or terms-used-for-capturing" is orthogonal to the question of "what to use as match-all symbol", though I understand the desire to repurpose the same symbol for both.
For a capturing sigil, "->", ">", ">>", "@", "?", "$" already were or can be proposed. The benefit of "->", ">", ">>" is that they're very intuitive. I'd also have preference for shorter one, because 2-chars are really verbose IMHO. OTOH, ">" has issue with parsing ambiguity unless separated by spaces ("Cls(kw1=>var)"). "$" is the worst choice IMHO, because intuitively (based on other languages - shell, etc.) it says "use the value of variable".
I'd still want to list "as" as another possibility, the advantage being that it's already used for binding elsewhere.
Well, the whole idea is that ">foo" syntax is a shortcut of "_ as foo" syntax of PEP634 or "foo := _" of PEP622. Such syntaxes otherwise would be rather verbose, why syntactic sugar for them would be beneficial.
On 13/11/20 8:21 am, Paul Sokolovsky wrote:
The current stage is to accept the fact that "mark capturing terms" is *very viable* alternative to "mark terms to use as values" ... But people behind PEPs keep ignoring that choice - silently, or with minimal consideration/commentary.
Their stated justification for this is that capturing will be used much more often than value matching. I'm not convinced about that -- how do they know? This is a feature unlike anything Python has had before. I don't think we can predict how people will use it.
Even if it's true, this seems to be prioritising writability over readability.
Marking the captures would be my preferred choice. I don't like the idea of DWIM heuristics for distinguishing values from captures, I'd prefer everything to be explicit. And it seems more logical to me to mark the captures rather than the values.
The vast majority of expressions in Python are interpreted as values, and assignment targets only occur in a few specially marked places -- on the LHS of an assignment, after "as", etc. I think the same principle should apply in match statements.
The only real disadvantage I can see is that it would make pattern matching substantially different from unpacking, but it's been stated that making these compatible is a non-goal, maybe even an anti-goal, and I'm fine with that.
On Thu, Nov 12, 2020 at 4:25 PM Greg Ewing greg.ewing@canterbury.ac.nz wrote:
On 13/11/20 8:21 am, Paul Sokolovsky wrote:
The current stage is to accept the fact that "mark capturing terms" is *very viable* alternative to "mark terms to use as values" ... But people behind PEPs keep ignoring that choice - silently, or with minimal consideration/commentary.
Their stated justification for this is that capturing will be used much more often than value matching. I'm not convinced about that -- how do they know? This is a feature unlike anything Python has had before. I don't think we can predict how people will use it.
Not too differently from how it's used in other languages that have it.
Even if it's true, this seems to be prioritising writability over readability.
No, that was never on our mind.
Marking the captures would be my preferred choice. I don't like the idea of DWIM heuristics for distinguishing values from captures, I'd prefer everything to be explicit. And it seems more logical to me to mark the captures rather than the values.
The vast majority of expressions in Python are interpreted as values, and assignment targets only occur in a few specially marked places -- on the LHS of an assignment, after "as", etc. I think the same principle should apply in match statements.
Not so few; there are many syntactic positions representing assignments or definitions. If you're looking for "what is x" you have to look at all of them, including def/class, parameters, import without 'as', for.
The only real disadvantage I can see is that it would make pattern matching substantially different from unpacking, but it's been stated that making these compatible is a non-goal, maybe even an anti-goal, and I'm fine with that.
We don't want to make them identical (because we can't, really), but we do like that they are pretty similar, since it will smooth learning (things don't have to be equal for learning by similarity to happen). This kind of syntactic "rhyme" is pretty important to me. Marking captures with sigils would destroy this.
participants (5)
-
Brett Cannon -
Greg Ewing -
Guido van Rossum -
MRAB -
Paul Sokolovsky