Mailing List Archive

On Sat, 18 Jul 2020 at 14:12, Steven D'Aprano <steve@pearwood.info> wrote:

> On Sat, Jul 18, 2020 at 09:25:45AM -0000,
> emmanuel.coirier@caissedesdepots.fr wrote:
>
> > This approach, for me, seems to come from functionnal languages where
> > pattern matching is a thing. The proposed "match" clause tends to
> > mimic this approach, and it can be a good thing. But the Python's
> > function definition has not been inspired by functionnal programming
> > from the ground, and I think it would be an error to reason this way,
> > because people not used to pattern matching in functionnal programming
> > won't understand anything (imagine that comprehension lists are a big
> > thing for many learners).
>
> It is true that beginners sometimes struggle a bit to grok comprehension
> syntax. I know I did.
>
> And yet, despite that, comprehensions have turned out to be one of the
> most powerful and popular features of Python, sometimes *too* popular.
> It is sometimes hard to convince both beginners and even experienced
> devs that comprehensions are not the only tool in their toolbox, and not
> every problem is a nail.
>
> You say: "people not used to pattern matching in functionnal programming
> won't understand anything" but people using Haskell weren't born knowing
> the language. They had to learn it.
>
> It's been sometimes said that functional programmers are smarter, elite
> programmers a level above the average OOP or procedural programmer, but
> that's mostly said by functional programmers :-) and I'm not entirely
> sure that its true. In any case, I don't think that any (actual or
> imaginary) gap between the ability of the average Haskell programmer and
> the average Python programmer is so great that we should dismiss pattern
> matching as beyond the grasp of Python coders.
>
> In any case, functional languages like Haskell, F# and ML are not the
> only languages with pattern matching. Non-FP languages like C#, Swift,
> Rust and Scala have it, and even Java has an extension providing pattern
> matching:
>
>
You do a nice job arguing that matching is a nice feature to have -
and I guess we are past this point.

But I don't see one thing in the above characters pointing that
using an undifferentiated name by itself in the match/case construct
will be better than trying to find a way to differentiate it,
and having significant gains in readability and "learnability"

Yes, people aren't born knowing Haskell, but then, one of the strong
points in Python is (or used to be) it _not looking_ like Haskell.

Having a differentiation sign for assignment would also allow
matching against values in variables just work in a very intuitive way,
just like it would have happened with the ".variable_name" in the first
version.

(I've written another e-mail on the thread, but since this scatters around:
my current bikeshed color is to _require_ the walrus op for
assignments like in: `case (x := _, y := _): ...` )

js
-><-


http://tom.loria.fr/wiki/index.php/Main_Page
>
>
> --
> Steven
>
>

I'm very new to this mailing list so I'm not sure it's my place to email, but I'd like to weigh in and maybe it will be useful. If not you can always ignore ;)

I think adding the Walrus operator is trying to solve a problem that doesn't exist. Compare the example from the PEP:
def make_point_3d(pt):
match pt:
case (x, y):
return Point3d(x, y, 0)
case (x, y, z):
return Point3d(x, y, z)
case Point2d(x, y):
return Point3d(x, y, 0)
case Point3d(_, _, _):
return pt
case _:
raise TypeError("not a point we support")
To the one without:
def make_point_3d(pt):
match pt:
case (x := _, y := _):
return Point3d(x, y, 0)
case (x := _, y := _, z := _):
return Point3d(x, y, z)
case Point2d(x := _, y := _):
return Point3d(x, y, 0)
case Point3d(_, _, _):
return pt
case _:
raise TypeError("not a point we support")
It's a lot more typing, it's a lot more ugly, and I'd argue it's not any more explicit than the earlier one. We still have all the same variables, except now we have to follow them with a ritualistic ":= _" to capture them. Normally we use the underscore to discard or hide something (at least that's how I've always used it), and suddenly it is used when we want to keep the thing it stands for?!

Also, I understand Python doesn't look like Haskell or Rust or whatever, but you also have people coming from those languages to Python, and people going to those languages from Python. Having a different syntax from what literally everybody else does will lead to a lot of confusion. I think the default option should be to have it like the current proposal (and everybody else), and update it only if there is a good reason to do so. "We don't want to look like the rest" should not be an argument. I think Python not looking like anything else is a result of the readability and simplicity goals of Python, not because the goal was to look different.

Finally, I asked an actual Python newbie (our trainee) about his opinion, and he said he didn't think the walrus example was any more useful. Of course, N=1, not an experiment, doesn't measure mistakes in practice, etc. But let's make sure it's an actual problem before we go complicate the syntax.

Again, first time mailing here and I don't know if it's my place (can I even mail into this list?), but I hope the perspective is of some use.

Rik

P.S. I never had issues with list comprehensions, because it's basically how you write down sets in mathematics (which is what I studied). 
"Joao S. O. Bueno" <jsbueno@python.org.br> wrote:
“”


“On Sat, 18 Jul 2020 at 14:12, Steven D'Aprano <steve@pearwood.info> wrote:”

“On Sat, Jul 18, 2020 at 09:25:45AM -0000, emmanuel.coirier@caissedesdepots.fr wrote:


> This approach, for me, seems to come from functionnal languages where

> pattern matching is a thing. The proposed "match" clause tends to

> mimic this approach, and it can be a good thing. But the Python's

> function definition has not been inspired by functionnal programming

> from the ground, and I think it would be an error to reason this way,

> because people not used to pattern matching in functionnal programming

> won't understand anything (imagine that comprehension lists are a big

> thing for many learners).


It is true that beginners sometimes struggle a bit to grok comprehension

syntax. I know I did.


And yet, despite that, comprehensions have turned out to be one of the

most powerful and popular features of Python, sometimes *too* popular.

It is sometimes hard to convince both beginners and even experienced

devs that comprehensions are not the only tool in their toolbox, and not

every problem is a nail.


You say: "people not used to pattern matching in functionnal programming

won't understand anything" but people using Haskell weren't born knowing

the language. They had to learn it.


It's been sometimes said that functional programmers are smarter, elite

programmers a level above the average OOP or procedural programmer, but

that's mostly said by functional programmers :-) and I'm not entirely

sure that its true. In any case, I don't think that any (actual or

imaginary) gap between the ability of the average Haskell programmer and

the average Python programmer is so great that we should dismiss pattern

matching as beyond the grasp of Python coders.


In any case, functional languages like Haskell, F# and ML are not the

only languages with pattern matching. Non-FP languages like C#, Swift,

Rust and Scala have it, and even Java has an extension providing pattern

matching:”
“
You do a nice job arguing that matching is a nice feature to have - and I guess we are past this point.

But I don't see one thing in the above characters pointing thatusing an undifferentiated name by itself in the match/case constructwill be better than trying to find a way to differentiate it,and having significant gains in readability and "learnability"
Yes, people aren't born knowing Haskell, but then, one of the strongpoints in Python is (or used to be) it _not looking_ like Haskell. 

Having a differentiation sign for assignment would also allow matching against values in variables just work in a very intuitive way,just like it would have happened with the ".variable_name" in the first version.
(I've written another e-mail on the thread, but since this scatters around: my current bikeshed color is to _require_ the walrus op for assignments like in:  `case (x := _, y := _): ...` )

   js -><-”

“http://tom.loria.fr/wiki/index.php/Main_Page



--

Steven”

[attachment.txt]

On 30/07/2020 00:34, Nick Coghlan wrote:
> the proposed name binding syntax inherently conflicts with the
> existing assignment statement lvalue syntax in two areas:
>
> * dotted names (binds an attribute in assignment, looks up a
> constraint value in a match case)
> * underscore targets (binds in assignment, wildcard match without
> binding in a match case)
>
>
> The former syntactic conflict presents a bigger problem, though, as it
> means that we'd be irrevocably committed to having two different
> lvalue syntaxes for the rest of Python's future as a language.
>
>
+1
_______________________________________________
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/WLNMH7OFURYPL2E7YT5JRYXW7RLDGIH6/
Code of Conduct: http://python.org/psf/codeofconduct/

Welcome to python-dev, Rik!  Of course you can email to this list.

On 30/07/2020 14:30, Rik de Kort via Python-Dev wrote:
>
> I think adding the Walrus operator is trying to solve a problem that
> doesn't exist. Compare the example from the PEP:
    [snip]
> case (x, y, z):
[snip]
>
> To the one without:
[snip]
> case (x := _, y := _, z := _):
> It's a lot more typing, it's a lot more ugly, and I'd argue it's not
> any more explicit than the earlier one.

The debate is still going on as to whether "capture" variables should be
marked, and if so whether with the walrus operator or in some other way,
and "var := _" wouldn't be my personal preference. However,

case (x := _, y := _, z := _):

*is* more explicit, because it explicitly says that x, y and z are
variables that should capture (i.e. be bound to) whatever values are
found.  Contrast this with say

case (x := _, y := _, z):

which says that z contains a value to be *matched*, and if such a match is found, x and y should capture the relevant values.

Best wishes
Rob Cliffe

On Wed, Jul 29, 2020 at 4:34 PM Nick Coghlan <ncoghlan@gmail.com> wrote:

> I'm still only intermittently keeping up on python-dev, but my main
> concern with the first iteration remains in this version, which is that it
> doesn't even *mention* that the proposed name binding syntax inherently
> conflicts with the existing assignment statement lvalue syntax in two areas:
>

I don't see why the PEP would be required to mention this. You make it
sound like it's a bad thing (a "conflict"), whereas the PEP authors'
position is that it is irrelevant.


> * dotted names (binds an attribute in assignment, looks up a constraint
> value in a match case)
> * underscore targets (binds in assignment, wildcard match without binding
> in a match case)
>
> The latter could potentially be made internally consistent in the future
> by redefining "_" and "__" as soft keywords that don't get bound via normal
> assignment statements either (requiring that they be set via namespace dict
> modification instead for use cases like il8n).
> https://www.python.org/dev/peps/pep-0622/#use-some-other-token-as-wildcard
> presents a reasonable rationale for the usage, so it's only flaw is failing
> to mention the inconsistency.
>

That solution is outside the scope of the PEP -- it would be a big backward
incompatibility with little payoff. Your repeated mention of consistency
makes me want to quote PEP 8 (quoting Emerson, though I didn't even know
who that was when I put it in my style guide :-): "A foolish consistency is
the hobgoblin of little minds."


> The former syntactic conflict presents a bigger problem, though, as it
> means that we'd be irrevocably committed to having two different lvalue
> syntaxes for the rest of Python's future as a language.
>

Things become much less "conflict-y" if you stop seeing patterns as
lvalues. They just aren't, and any argument based on the idea that they are
is inherently flawed. (Also note that the concept of lvalue isn't even
defined in Python. There are a variety of assignment targets with different
syntactic constraints depending on context, and several other syntactic
constructs that bind names.)


>
> https://www.python.org/dev/peps/pep-0622/#alternatives-for-constant-value-pattern
> is nominally about this problem, but it doesn't even *mention* the single
> biggest benefit of putting a common prefix on value constraints: it leaves
> the door open to unifying the lvalue syntax again in the future by keeping
> the proposed match case syntax a strict superset of the existing assignment
> target syntax, rather than partially conflicting with it.
>

That's because the PEP authors disagree with you that this goal is worthy
of pursuit, and hence we don't see care about this benefit at all.


> More incidentally, the latest write-up also leaves out "?" as a suggested
> constraint value prefix, when that's the single character prefix that best
> implies the question "Does the runtime value at this position equal the
> result of this value constraint expression?" without having any other
> existing semantic implications in Python.
>

In the discussion pretty much all non-alphanumeric ASCII characters have
been proposed by various people as sigils to mark either capture patterns
or value patterns. We didn't think it was necessary to enumerate all
proposed characters and write up reasons why we reject them, since the
reasons for rejection are pretty much always the same -- it looks strange,
and there's no need for sigils at all.

Honestly, it doesn't help the case for `?` that it's been proposed as a
mark for both capture patterns and value patterns (by different people,
obviously :-).


> Cheers,
> Nick.
>
> P.S. I feel I should mention that the other reason I like "?" as a
> potential prefix for value constraints is that if we require it for all
> value constraint expressions (both literals and name lookups) I believe it
> could offer a way to unblock the None-aware expressions PEP by reframing
> that PEP as a shorthand for particular case matches.
>
> None coalescence ("a ?? b") for example:
>
> match a:
> case ?None:
> _expr_result = b
> case _match:
> _expr_result = _match
>
> Or a None-severing attribute lookup ("a?.b"):
>
> _match_expr = a
> match _match_expr:
> case ?None:
> _expr_result = _match_expr
> case _match:
> _expr_result = _match.b
>
> Since these operations would be defined in terms of *equality* (as per PEP
> 622), rather than identity, it would also allow other sentinels to benefit
> from the None-aware shorthand by defining themselves as being equal to None.
>

This sounds like a huge stretch. Trying to forge a connection between two
separate uses of the same character sounds like arguing that the `*` in `a
* b` and the `*` in `*args` are really the same operator.

I am actually rather in favor of PEP 505, but that doesn't make any
difference for how I see marking value patterns in PEP 622.

--Guido


> On Thu., 9 Jul. 2020, 1:07 am Guido van Rossum, <guido@python.org> wrote:
>
>> Today I’m happy (and a little trepidatious) to announce the next
>> version of PEP 622, Pattern Matching. [...]
>>
>
--
--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-change-the-world/>

Hi Rob, thank you! :)
I think I understand the point, but I still don't agree with it. I find it hard to come up with a concrete use case where you would like to name a parameter without specifying it. Suppose we want
case Status(user, n_messages, replies, unicode:=_)
Then it might be a little useful for us to type the non-captured arguments explicitly because it's easier to remember the signature that way. Alternatively, if you want to capture an arg like this and you have more than a few positional arguments, you should probably just match on a keyword argument (or refactor your code so your API's are simpler).
Also, what would we type if we wanted to capture a keyword argument? Something like this?
case Status(user, n_messages, replies, unicode=unicode:=_)
Surely that must be a horrible joke! (N.B. I suppose this is an argument against this specific syntax rather than capturing)

Additional potentials I came up with are checking for the number of arguments (when it's a lot, so typing all the underscores becomes hard to count), like:
match pt:
case (a, b, c, d, e, f, g, h):
manage_len_8(pt)
case (a, b, c, d, e, f, g, h, i, j, k):
manage_len_11(pt)
But in that case why not use an if-else, like so.
if len(pt)==8:
manage_len_8(pt)
elif len(pt)==11:
manage_len_11(pt)
There must be use cases I haven't thought of, but I think they will all fall prey to similar objections as the above two. I'm open to being proven wrong, though!

The thing about explicitness is, sure, it is better than implicitness. But beautiful is also better than ugly, and simple better than complex, etc. etc. I think they mean nothing without specific use cases to know what it actually means for this thing in this context.
I think case(x:=_, y:=_, z) is exactly as explicit as case(x, y, _) (it names x and y explicitly), with the added drawbacks of
- Confusing the meaning of "_", which (at least in my mind) means "discard".
- Deviating from other languages with pattern matching (which, presumably, also have bikeshedded on this point), increasing the surprise level for people who are either coming to Python from there, or going from Python to there.
- Requiring extra (weird-looking) syntax for the default case of capturing variables.

Again, maybe I'm just having trouble finding good use cases (either that, or I have no intuition for programming :P). Let me know if you have some!

Rik

P.S. If I'm out of line or violating etiquette with anything, please let me know. I'm open to help.

On 08/07/2020 16:02, Guido van Rossum wrote:
> Today I’m happy (and a little trepidatious) to announce the next
> version of PEP 622, Pattern Matching.
After all the discussion on the issue, I can still not stop thinking
that there needs to be a visual distinction between "capture" and
"match" variables.
Having rules ("plain names are capture, dotted names are match") is one
more thing to be learnt.  One more bit of mystery when (a near newbie
is) reading code.

Possible compromise: *two* sigils - one for capture, one for match. Both
would be optional, only required when the default is not what is wanted,
but could be added regardless if the author felt it added clarity.

_______________________________________________
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/6RD4RMT55TCKTVYCO7DWBMP7LNSZQ6BR/
Code of Conduct: http://python.org/psf/codeofconduct/

Adding this feature would be a giant quality of life improvement for me and
I really hope it succeeds. So I have been trying to keep up on the debate
in this and related thread.

While I do want this feature, I agree with a lot of the issues people are
raising.

First I agree that _ should not be the wildcard symbol. Or rather the
hobgoblins in my mind think that if _ is to be the wildcard symbol it would
be more consistent with assignment if it was bound to the last value it was
matched with (as should other repeated identifiers) e.g.,

match pt:
case (x, _, _):
assert _ == pt[2]

I understand the authors rationalize the decision based on conventions with
the gettext module. I find these arguments very unconvincing. It's like
saying the identifier np should be forbidden from appearing in cases
because it's frequently used as the name of numpy. If there is to be a
wildcard symbol (that does not bind and is repeatable) it should not be a
valid identifier.

Second, the distinction between a capture and constant value pattern
should be more explicit. I don't have any great insight into the color of
the shed beyond the numerous suggestions already made (name=, ?name,
etc...), but it seems quite unintuitive to me that I can't capture into a
namespace nor match a constant without a namespace. It is also unclear to
me why it would be so terrible to add a new token or abuse an existing one.

> Honestly, it doesn't help the case for `?` that it's been proposed as a
mark for both capture patterns and value patterns (by different people,
obviously :-).

I agree that most of the proposed sheds don't necessarily make it
intuitively clear what is a capture variable vs what is a constant.
However they do give the programmer the ability to choose.

For example if I want to modify the motivating example from the PEP
slightly to copy attributes from one point to another I can't express it
concisely:

def update_point_3d(p: Point3d, pt):
match pt:
case (x, y):
p.x, p.y = x, y
case Point2d(x, y):
p.x, p.y = x, y
...


(Okay I could have just called the original make_point_3d and unpacked the
results but it would require the creation of an unnecessary temporary.)

However if the capture was explicit and any valid target could be used as a
capture variable then I could express this cleanly:

def update_point_3d(p: Point3d, pt):
match pt:
case (p.x=, p.y=):
pass
case Point2d(p.x=, p.y=):
pass
...


- Caleb Donovick

On 7/30/20 4:31 PM, Caleb Donovick wrote:
> However if the capture was explicit and any valid target could be used
> as a capture variable then I could express this cleanly:
> |def update_point_3d(p: Point3d, pt): match pt: case (p.x=, p.y=):
> pass case Point2d(p.x=, p.y=): pass ... |


I like this proposal, using = to explicitly specify when capturing.  I
see it as a big improvement over the current PEP where dotted names are
never assigned to and non-dotted names usually are.  It also leads
directly to an alternate proposal for the wildcard pattern: a "=" not
prefaced with an lvalue.  This has the benefit of having no conflict
with i18n, etc.


Explicit is better than implicit,


//arry/

Hi Caleb,

I will only answer to the second part, as the wildcard issue has
been brought up and discussed time and again, and the `np`
analogue is quite a stretch and far-fetched, really.

One thing that stood out a bit to me as I feel to have seen it a
couple of times is the question of intuition, so I will add a few
more general thoughts to that...

> [...] but it  seems quite unintuitive to me [...]

> [...] don't necessarily make it intuitively clear [...]

 

Intuition (or lack thereof) has already been brought forward
as an argument a couple of times.  I would just like to briefly
point out that there is no such thing as universal intuition in
the field of programming.  We all have different training,
skills, preferences and experiences, which make up what
we call 'intuition'.  But what is intuitive is usually something
completely different to C-programmer than to a Haskell- or
Lisp-Programmer, say.  And since pattern matching is really
a new feature to be introduced to Python, a feature that can
be seen in different lights, there is no 'Python-Programmer
intuition' that would apply in this case.

As for beginners, virtually every part of programming is
unintuitive at first.  Even something innocuous-looking like
assignment is often reason for confusion because `3 + 4 = x`
would probably be more 'intuitive'.  But there is good reason
with regards to the bigger picture to stick to `x = 3 + 4`.

A Python-programmer (at any level) not familiar with pattern
matching will most likely not understand all subtlety of the
syntax---but this is alos true of features like `async` or the
`/` in parameters, say.  I would argue, though, that the clear
choice of keywords allow anyone to quickly look pattern
matching up and get informed on what it does.  So, we do
not need to come with something that is entirely 'intuitive'
and 'self-evident'.  But by sticking to common convention
like `_` as wildcard, we can help quickly build the correct
intuition.

In your examples, for instance, it is perfectly obvious to me
that you cannot directly assign to attributes and it would in
fact look very weird to my eyes if you could.  Your use case
is quite similar to initialisers and you are arguing that you
would like being able to write:
```
CLASS Point:
    DEF __init__(self, self.x, self.y):
        PASS
```
rather than the more verbose:
```
CLASS Point:
    DEF __init__(self, x, y):
        self.x, self.y = x, y
```
I do not think that this would be a good idea for either
parameters or patterns.  After all, pattern matching is
*/not/* assignment, even though it is related to it, of
course.

Kind regards,
Tobias

Quoting Caleb Donovick <donovick@cs.stanford.edu>:

> Adding this feature would be a giant quality of life improvement for
> me and I really hope it succeeds.  So I have been trying to keep up
> on the debate in this and related thread.
>
> While I do want this feature,  I agree with a lot of the issues
> people are raising.
>
> First I agree that _ should not be the wildcard symbol.  Or rather
> the hobgoblins in my mind think that if _ is to be the wildcard
> symbol it would be more consistent with assignment if it was bound
> to the last value it was matched with (as should other repeated
> identifiers) e.g.,
> match pt: case (x, _, _): assert _ == pt[2]  
> I understand the authors rationalize the decision based on
> conventions with the gettext module.  I find these arguments very
> unconvincing.  It's like saying the identifier np should be
> forbidden from appearing in cases because it's frequently used as
> the name of numpy.  If there is to be a wildcard symbol (that does
> not bind and is repeatable) it should not be a valid identifier. 
>
> Second,  the distinction between a capture and constant value
> pattern should be more explicit.  I don't have any great insight
> into the color of the shed beyond the numerous suggestions already
> made (name=, ?name, etc...), but it  seems quite unintuitive to me
> that I can't capture into a namespace nor match a constant without a
> namespace.  It is also unclear to me why it would be so terrible to
> add a new token or abuse an existing one.
>
> > Honestly, it doesn't help the case for `?` that it's been
> proposed as a mark for both capture patterns and value patterns (by
> different people, obviously :-).
>
> I agree that most of the proposed sheds don't necessarily make
> it intuitively clear what is a capture variable vs what is a
> constant.  However they do give the programmer the ability to choose.
>
> For example if I want to modify the motivating example from the PEP
> slightly to copy attributes from one point to another I can't
> express it concisely:
> def update_point_3d(p: Point3d, pt): match pt: case
> (x, y): p.x, p.y = x, y case Point2d(x, y):
> p.x, p.y = x, y ...  
>
>
> (Okay I could have just called the original make_point_3d and
> unpacked the results but it would require the creation of an
> unnecessary temporary.)
>
> However if the capture was explicit and any valid target could
> be used as a capture variable then I could express this cleanly:
> def update_point_3d(p: Point3d, pt): match
> pt: case (p.x=, p.y=): pass case
> Point2d(p.x=, p.y=): pass ...  
>
>  - Caleb Donovick
>  
>  

On 7/31/20 12:36 AM, Tobias Kohn wrote:
>
> And since pattern matching is really
> a new feature to be introduced to Python, a feature that can
> be seen in different lights, there is no 'Python-Programmer
> intuition' that would apply in this case.
>
It's not fair to say "intuition doesn't apply because it's new syntax".?
There are plenty of examples of intuition serving a Python programmer
well when encountering new syntax.? A Python programmer's intuition is
informed by existing syntax and conventions in the language.? When they
see a new construct, its similarity to existing constructs can make
understanding the new syntax quite intuitive indeed.

Take for example list comprehensions.? Python 1 programmers hadn't seen

a = [x for x in y]

But they knew what square brackets meant in that context, it meant
"creates a new list".? And they knew what "for x in y" meant, that meant
iteration.? Understanding those separate two concepts, a Python 1
programmer would be well on their way to guessing what the new syntax
meant--and they'd likely be right. And once they understood list
comprehensions, the first time they saw generator expressions and set
and dict comprehensions they'd surely intuit what those did immediately.

The non-intuitiveness of PEP 622, as I see it, is that it repurposes
what looks like existing Python syntax but frequently has wholly
different semantics.? For example, a "class pattern" looks like it's
calling a function--perhaps instantiating an object?--but the actual
semantics and behavior is very different. Similarly, a "mapping pattern"
looks like it's instantiating a dict, but it does something very
different, and has unfamiliar and seemingly arbitrary rules about what
is permitted, e.g. you can't use full expressions or
undotted-identifiers when defining a key. Add the "capture pattern" to
both of these, and a Python programmer's intuition about what this
syntax traditionally does will be of little help when encountering a PEP
622 match statement for the first time.

Cheers,


//arry/

+10. See https://stackoverflow.com/questions/36825925/expressions-with-true-and-is-true-give-different-results/36826262#36826262 for
concrete evidence where another semantically inconsistent operator overloading caused trouble and what Stroustroup has to say on the matter.

On 31.07.2020 13:42, Larry Hastings wrote:
>
>
> On 7/31/20 12:36 AM, Tobias Kohn wrote:
>>
>> And since pattern matching is really
>> a new feature to be introduced to Python, a feature that can
>> be seen in different lights, there is no 'Python-Programmer
>> intuition' that would apply in this case.
>>
> It's not fair to say "intuition doesn't apply because it's new syntax".? There are plenty of examples of intuition serving a Python
> programmer well when encountering new syntax.? A Python programmer's intuition is informed by existing syntax and conventions in the
> language.? When they see a new construct, its similarity to existing constructs can make understanding the new syntax quite intuitive indeed.
>
> Take for example list comprehensions.? Python 1 programmers hadn't seen
>
> a = [x for x in y]
>
> But they knew what square brackets meant in that context, it meant "creates a new list".? And they knew what "for x in y" meant, that
> meant iteration.? Understanding those separate two concepts, a Python 1 programmer would be well on their way to guessing what the new
> syntax meant--and they'd likely be right. And once they understood list comprehensions, the first time they saw generator expressions and
> set and dict comprehensions they'd surely intuit what those did immediately.
>
> The non-intuitiveness of PEP 622, as I see it, is that it repurposes what looks like existing Python syntax but frequently has wholly
> different semantics.? For example, a "class pattern" looks like it's calling a function--perhaps instantiating an object?--but the actual
> semantics and behavior is very different.? Similarly, a "mapping pattern" looks like it's instantiating a dict, but it does something very
> different, and has unfamiliar and seemingly arbitrary rules about what is permitted, e.g. you can't use full expressions or
> undotted-identifiers when defining a key.? Add the "capture pattern" to both of these, and a Python programmer's intuition about what this
> syntax traditionally does will be of little help when encountering a PEP 622 match statement for the first time.
>
> Cheers,
>
>
> //arry/
>
>
> _______________________________________________
> 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/Q5KULD7E3TZSSQ5CFUOQSJTGS5JQS4WM/
> Code of Conduct: http://python.org/psf/codeofconduct/
> --
> Regards,
> Ivan

1. Semantic operator overloading in generic contexts is very different from this use case. It's surrounded by a clear context.
2. Python programmer intuition varies across python programmers, and I would find it hella unintuitive if I had to explicitly capture every variable. I just want to write down what the thing looks like and have the interpreter figure out the correct bindings. Extra binding syntax will get in the way rather than be helpful.
Python Dev <python-dev@python.org> wrote:
“+10. See https://stackoverflow.com/questions/36825925/expressions-with-true-and-is-true-give-different-results/36826262#36826262 for concrete evidence where another semantically inconsistent operator overloading caused trouble and what Stroustroup has to say on the matter.
 

On 31.07.2020 13:42, Larry Hastings wrote:

“

 

On 7/31/20 12:36 AM, Tobias Kohn wrote:“And since pattern matching is really
 a new feature to be introduced to Python, a feature that can
 be seen in different lights, there is no 'Python-Programmer
 intuition' that would apply in this case.
 ”

It's not fair to say "intuition doesn't apply because it's new syntax".  There are plenty of examples of intuition serving a Python programmer well when encountering new syntax.  A Python programmer's intuition is informed by existing syntax and conventions in the language.  When they see a new construct, its similarity to existing constructs can make understanding the new syntax quite intuitive indeed.

Take for example list comprehensions.  Python 1 programmers hadn't seen

“a = [x for x in y]
 ”

But they knew what square brackets meant in that context, it meant "creates a new list".  And they knew what "for x in y" meant, that meant iteration.  Understanding those separate two concepts, a Python 1 programmer would be well on their way to guessing what the new syntax meant--and they'd likely be right.  And once they understood list comprehensions, the first time they saw generator expressions and set and dict comprehensions they'd surely intuit what those did immediately.
 

The non-intuitiveness of PEP 622, as I see it, is that it repurposes what looks like existing Python syntax but frequently has wholly different semantics.  For example, a "class pattern" looks like it's calling a function--perhaps instantiating an object?--but the actual semantics and behavior is very different.  Similarly, a "mapping pattern" looks like it's instantiating a dict, but it does something very different, and has unfamiliar and seemingly arbitrary rules about what is permitted, e.g. you can't use full expressions or undotted-identifiers when defining a key.  Add the "capture pattern" to both of these, and a Python programmer's intuition about what this syntax traditionally does will be of little help when encountering a PEP 622 match statement for the first time.
 

Cheers,
 


 

/arry
 



_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.orghttps://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/Q5KULD7E3TZSSQ5CFUOQSJTGS5JQS4WM/
Code of Conduct: http://python.org/psf/codeofconduct/
-- 
 Regards,
 Ivan””

[attachment.txt]

On 31/07/2020 17:24, Rik de Kort via Python-Dev wrote:
> 1. Semantic operator overloading in generic contexts is very different
> from this use case. It's surrounded by a clear context.
> 2. Python programmer intuition varies across python programmers, and I
> would find it hella unintuitive if I had to explicitly capture every
> variable. I just want to write down what the thing looks like and have
> the interpreter figure out the correct bindings. Extra binding syntax
> will get in the way rather than be helpful.

Until you want to do something slightly different, and the interpreter's
choice is not what you want.
>
> Python Dev <python-dev@python.org> wrote:
>
> +10. See
> https://stackoverflow.com/questions/36825925/expressions-with-true-and-is-true-give-different-results/36826262#36826262
> for concrete evidence where another semantically inconsistent
> operator overloading caused trouble and what Stroustroup has to
> say on the matter.
>
>
> On 31.07.2020 13:42, Larry Hastings wrote:
>
>
>
>
>
> On 7/31/20 12:36 AM, Tobias Kohn wrote:
>
> And since pattern matching is really
>  a new feature to be introduced to Python, a feature that can
>  be seen in different lights, there is no 'Python-Programmer
>  intuition' that would apply in this case.
>
>
> It's not fair to say "intuition doesn't apply because it's new
> syntax".  There are plenty of examples of intuition serving a
> Python programmer well when encountering new syntax.  A Python
> programmer's intuition is informed by existing syntax and
> conventions in the language.  When they see a new construct,
> its similarity to existing constructs can make understanding
> the new syntax quite intuitive indeed.
>
> Take for example list comprehensions.  Python 1 programmers
> hadn't seen
>
> a = [x for x in y]
>
>
> But they knew what square brackets meant in that context, it
> meant "creates a new list".  And they knew what "for x in y"
> meant, that meant iteration.  Understanding those separate two
> concepts, a Python 1 programmer would be well on their way to
> guessing what the new syntax meant--and they'd likely be
> right.  And once they understood list comprehensions, the
> first time they saw generator expressions and set and dict
> comprehensions they'd surely intuit what those did immediately.
>
>
> The non-intuitiveness of PEP 622, as I see it, is that it
> repurposes what looks like existing Python syntax but
> frequently has wholly different semantics.  For example, a
> "class pattern" looks like it's calling a function--perhaps
> instantiating an object?--but the actual semantics and
> behavior is very different.  Similarly, a "mapping pattern"
> looks like it's instantiating a dict, but it does something
> very different, and has unfamiliar and seemingly arbitrary
> rules about what is permitted, e.g. you can't use full
> expressions or undotted-identifiers when defining a key.  Add
> the "capture pattern" to both of these, and a Python
> programmer's intuition about what this syntax traditionally
> does will be of little help when encountering a PEP 622 match
> statement for the first time.
>
>
> Cheers,
>
>
>
>
>
> //arry/
>
>
>
>
> _______________________________________________
>
> Python-Dev mailing list --python-dev@python.org <mailto:python-dev@python.org>
>
> To unsubscribe send an email topython-dev-leave@python.org <mailto:python-dev-leave@python.org>
>
> https://mail.python.org/mailman3/lists/python-dev.python.org/
>
> Message archived athttps://mail.python.org/archives/list/python-dev@python.org/message/Q5KULD7E3TZSSQ5CFUOQSJTGS5JQS4WM/
>
> Code of Conduct:http://python.org/psf/codeofconduct/
>
>
> --
>  Regards,
>  Ivan
>
>
> _______________________________________________
> 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/4L7LXGVYTMHPF5I54Z2DVSIKSL75ES6H/
> Code of Conduct: http://python.org/psf/codeofconduct/

On Fri., 31 Jul. 2020, 3:14 am Guido van Rossum, <guido@python.org> wrote:

> On Wed, Jul 29, 2020 at 4:34 PM Nick Coghlan <ncoghlan@gmail.com> wrote:
>
>> I'm still only intermittently keeping up on python-dev, but my main
>> concern with the first iteration remains in this version, which is that it
>> doesn't even *mention* that the proposed name binding syntax inherently
>> conflicts with the existing assignment statement lvalue syntax in two areas:
>>
>
> I don't see why the PEP would be required to mention this. You make it
> sound like it's a bad thing (a "conflict"), whereas the PEP authors'
> position is that it is irrelevant.
>
>
>> * dotted names (binds an attribute in assignment, looks up a constraint
>> value in a match case)
>> * underscore targets (binds in assignment, wildcard match without binding
>> in a match case)
>>
>> The latter could potentially be made internally consistent in the future
>> by redefining "_" and "__" as soft keywords that don't get bound via normal
>> assignment statements either (requiring that they be set via namespace dict
>> modification instead for use cases like il8n).
>> https://www.python.org/dev/peps/pep-0622/#use-some-other-token-as-wildcard
>> presents a reasonable rationale for the usage, so it's only flaw is failing
>> to mention the inconsistency.
>>
>
> That solution is outside the scope of the PEP -- it would be a big
> backward incompatibility with little payoff. Your repeated mention of
> consistency makes me want to quote PEP 8 (quoting Emerson, though I didn't
> even know who that was when I put it in my style guide :-): "A foolish
> consistency is the hobgoblin of little minds."
>

I don't really like that future possibility either - I think it would be
much better for PEP 622 to let "_" be a binding throwaway variable as
normal, and allow a bare "?" as the "match any expression without binding
it" marker.

But unlike the reuse of attribute assignment syntax for a different
purpose, it's a conflict that I don't think matters very much (as it's
incredibly rare to care whether binding "_" actually creates a reference or
not, so having it bind sometimes and not others isn't likely to present any
major barriers to learning).

>
> The former syntactic conflict presents a bigger problem, though, as it
>> means that we'd be irrevocably committed to having two different lvalue
>> syntaxes for the rest of Python's future as a language.
>>
>
> Things become much less "conflict-y" if you stop seeing patterns as
> lvalues. They just aren't, and any argument based on the idea that they are
> is inherently flawed.
>

That's conceding my point, though: aside from iterable unpacking, the PEP
isn't currently even trying to keep pattern matching syntax consistent with
assignment target syntax, as the PEP authors haven't even considered the
idea of pursuing a higher level of consistency as a design goal.

A section titled "Match patterns are not assignment targets" that explains
that even though match patterns bind names and do iterable unpacking the
same way assignment targets do, it is nevertheless incorrect for a reader
to think of them as assignment targets would address my concern (it
wouldn't convince me that it is a good idea to view the design problem that
way, but I would accept that the argument had been heard and addressed in a
context where the future PEP delegate will necessarily see it).

(Also note that the concept of lvalue isn't even defined in Python. There
> are a variety of assignment targets with different syntactic constraints
> depending on context, and several other syntactic constructs that bind
> names.)
>

Right, I just use "lvalue" as a shorthand for "syntax that can bind a
name". All the others are strict subsets of the full assignment target
syntax, though, mostly falling into either "simple names only" or "simple
names and iterable unpacking, but no attributes or subscripts". I'll use
"name binding context" for the full set of those below.

This PEP is the first time it has been proposed to accept valid assignment
target syntax in a name binding context, but have it mean something
different.
The fact that the PEP doesn't even acknowledge that this is a potential
problem is the biggest part of the problem. If the problem was
acknowledged, and addressed, then readers could evaluate the merits of PEP
authors' arguments against it.

As it is, unless the reader identifies the conflict on their own, they may
not realise what is bugging them about it, and make the same mistake I
initially did and believe it's the binding syntax that's inconsistent (when
that's actually entirely consistent with for loops, for example), rather
than the constraint lookup syntax (which has never previously been allowed
in a name binding context).

We know the PEP authors don't see patterns as assignment targets beyond
sharing the iterable unpacking syntax, but my concern is for everyone
*else* that is either learning pattern matching as an existing Python
developer, or learning Python in general after match statements are added,
and is trying to figure out why these two snippets do the same thing:

x = y

match y:
case x:
pass

and so do these:

a, b = x, y

match (x, y):
case a, b:
pass

while the second snippet here throws NameError if the attribute doesn't
exist yet, or silently does nothing if it does:

x.a = y

match y:
case x.a:
pass

If that consistently threw SyntaxError instead (which is what I am
suggesting it should do in the absence of a leading "?" on the constraint
expression), then it would be similar to the many other places where we
allow binding simple names and iterable unpacking, but not attributes or
subscripts.

As it is, it's the tipping point where learners will be forced to realise
that there is a semantic inconsistency between pattern matching syntax and
assignment target syntax.

If the PEP authors are deliberately championing that inconsistency, then it
will be up to the PEP delegate to decide if it is a deal breaker or not.
But right now, the PEP isn't even acknowledging that this is a significant
design decision that the PEP authors have made.

Cheers,
Nick.


>

<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
>

Trust me, the PEP authors are well aware. If we hadn't been from the
outset, a hundred different proposals to "deal" with this would have. And
many of those proposals actually made it into the list of rejected ideas.
Moreover, we rewrote a huge portion of the PEP from scratch as a result
(everything from Abstract up to the entire Rationale and Goals section).

Apart from your insistence that we "acknowledge" an "inconsistency", your
counter-proposal is not so different from the others.

Let's agree to disagree on the best syntax for patterns.

On Fri, Jul 31, 2020 at 5:21 PM Nick Coghlan <ncoghlan@gmail.com> wrote:

>
>
> On Fri., 31 Jul. 2020, 3:14 am Guido van Rossum, <guido@python.org> wrote:
>
>> On Wed, Jul 29, 2020 at 4:34 PM Nick Coghlan <ncoghlan@gmail.com> wrote:
>>
>>> I'm still only intermittently keeping up on python-dev, but my main
>>> concern with the first iteration remains in this version, which is that it
>>> doesn't even *mention* that the proposed name binding syntax inherently
>>> conflicts with the existing assignment statement lvalue syntax in two areas:
>>>
>>
>> I don't see why the PEP would be required to mention this. You make it
>> sound like it's a bad thing (a "conflict"), whereas the PEP authors'
>> position is that it is irrelevant.
>>
>>
>>> * dotted names (binds an attribute in assignment, looks up a constraint
>>> value in a match case)
>>> * underscore targets (binds in assignment, wildcard match without
>>> binding in a match case)
>>>
>>> The latter could potentially be made internally consistent in the future
>>> by redefining "_" and "__" as soft keywords that don't get bound via normal
>>> assignment statements either (requiring that they be set via namespace dict
>>> modification instead for use cases like il8n).
>>> https://www.python.org/dev/peps/pep-0622/#use-some-other-token-as-wildcard
>>> presents a reasonable rationale for the usage, so it's only flaw is failing
>>> to mention the inconsistency.
>>>
>>
>> That solution is outside the scope of the PEP -- it would be a big
>> backward incompatibility with little payoff. Your repeated mention of
>> consistency makes me want to quote PEP 8 (quoting Emerson, though I didn't
>> even know who that was when I put it in my style guide :-): "A foolish
>> consistency is the hobgoblin of little minds."
>>
>
> I don't really like that future possibility either - I think it would be
> much better for PEP 622 to let "_" be a binding throwaway variable as
> normal, and allow a bare "?" as the "match any expression without binding
> it" marker.
>
> But unlike the reuse of attribute assignment syntax for a different
> purpose, it's a conflict that I don't think matters very much (as it's
> incredibly rare to care whether binding "_" actually creates a reference or
> not, so having it bind sometimes and not others isn't likely to present any
> major barriers to learning).
>
>>
>> The former syntactic conflict presents a bigger problem, though, as it
>>> means that we'd be irrevocably committed to having two different lvalue
>>> syntaxes for the rest of Python's future as a language.
>>>
>>
>> Things become much less "conflict-y" if you stop seeing patterns as
>> lvalues. They just aren't, and any argument based on the idea that they are
>> is inherently flawed.
>>
>
> That's conceding my point, though: aside from iterable unpacking, the PEP
> isn't currently even trying to keep pattern matching syntax consistent with
> assignment target syntax, as the PEP authors haven't even considered the
> idea of pursuing a higher level of consistency as a design goal.
>
> A section titled "Match patterns are not assignment targets" that explains
> that even though match patterns bind names and do iterable unpacking the
> same way assignment targets do, it is nevertheless incorrect for a reader
> to think of them as assignment targets would address my concern (it
> wouldn't convince me that it is a good idea to view the design problem that
> way, but I would accept that the argument had been heard and addressed in a
> context where the future PEP delegate will necessarily see it).
>
> (Also note that the concept of lvalue isn't even defined in Python. There
>> are a variety of assignment targets with different syntactic constraints
>> depending on context, and several other syntactic constructs that bind
>> names.)
>>
>
> Right, I just use "lvalue" as a shorthand for "syntax that can bind a
> name". All the others are strict subsets of the full assignment target
> syntax, though, mostly falling into either "simple names only" or "simple
> names and iterable unpacking, but no attributes or subscripts". I'll use
> "name binding context" for the full set of those below.
>
> This PEP is the first time it has been proposed to accept valid assignment
> target syntax in a name binding context, but have it mean something
> different.
> The fact that the PEP doesn't even acknowledge that this is a potential
> problem is the biggest part of the problem. If the problem was
> acknowledged, and addressed, then readers could evaluate the merits of PEP
> authors' arguments against it.
>
> As it is, unless the reader identifies the conflict on their own, they may
> not realise what is bugging them about it, and make the same mistake I
> initially did and believe it's the binding syntax that's inconsistent (when
> that's actually entirely consistent with for loops, for example), rather
> than the constraint lookup syntax (which has never previously been allowed
> in a name binding context).
>
> We know the PEP authors don't see patterns as assignment targets beyond
> sharing the iterable unpacking syntax, but my concern is for everyone
> *else* that is either learning pattern matching as an existing Python
> developer, or learning Python in general after match statements are added,
> and is trying to figure out why these two snippets do the same thing:
>
> x = y
>
> match y:
> case x:
> pass
>
> and so do these:
>
> a, b = x, y
>
> match (x, y):
> case a, b:
> pass
>
> while the second snippet here throws NameError if the attribute doesn't
> exist yet, or silently does nothing if it does:
>
> x.a = y
>
> match y:
> case x.a:
> pass
>
> If that consistently threw SyntaxError instead (which is what I am
> suggesting it should do in the absence of a leading "?" on the constraint
> expression), then it would be similar to the many other places where we
> allow binding simple names and iterable unpacking, but not attributes or
> subscripts.
>
> As it is, it's the tipping point where learners will be forced to realise
> that there is a semantic inconsistency between pattern matching syntax and
> assignment target syntax.
>
> If the PEP authors are deliberately championing that inconsistency, then
> it will be up to the PEP delegate to decide if it is a deal breaker or not.
> But right now, the PEP isn't even acknowledging that this is a significant
> design decision that the PEP authors have made.
>
> Cheers,
> Nick.
>
>
>>
>
>
>> <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
>>
>

--
--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-change-the-world/>

On Sat., 1 Aug. 2020, 10:55 am Guido van Rossum, <guido@python.org> wrote:

> Trust me, the PEP authors are well aware. If we hadn't been from the
> outset, a hundred different proposals to "deal" with this would have. And
> many of those proposals actually made it into the list of rejected ideas.
> Moreover, we rewrote a huge portion of the PEP from scratch as a result
> (everything from Abstract up to the entire Rationale and Goals section).
>
> Apart from your insistence that we "acknowledge" an "inconsistency", your
> counter-proposal is not so different from the others.
>

Right, there are several ways the PEP could be adjusted so that assignment
target syntax and pattern matching syntax had consistent semantics whenever
they share syntax, just as other name binding syntaxes are already strict
subsets of the full assignment target syntax. I personally like "Use '?' as
an explicit constraint expression prefix", but it's far from being the only
possibility.

But if we don't even agree that common syntax in a name binding context
should either always mean the same thing, or else be a syntax error, then
we're not going to agree that there's a problem to be solved in the first
place.

Let's agree to disagree on the best syntax for patterns
>

I think our disagreement is more fundamental than that, as I believe there
should be a common metasyntax for imperative name binding (i.e. everything
except function parameters) that all actual name binding contexts allow a
subset of, while the PEP authors feel it's OK to treat pattern matching as
a completely new design entity that only incidentally shares some common
syntax with assignment targets.

Prior to PEP 622, the apparent design constraint that I had inferred was
implicitly met by the fact that all the imperative name binding operations
accept a subset of the full assignment target syntax, so it's never
actually come up before whether this is a real design goal for the
language, or just a quirk of history.

PEP 622 is forcing that question to be answered explicitly, as accepting it
in its current form would mean telling me, and everyone else that had
inferred a similar design concept, that we need to adjust our thinking.

I'd obviously prefer it if the PEP chose a different syntax that avoided
the semantic conflict with assignment for dotted names, but in the absence
of that, I'd settle for the explicit statement that we're wrong and
inferred a design principle that never actually existed.

Cheers,
Nick.




>
>

That's a strawman argument. I am done arguing about this.

On Fri, Jul 31, 2020 at 7:47 PM Nick Coghlan <ncoghlan@gmail.com> wrote:

>
>
> On Sat., 1 Aug. 2020, 10:55 am Guido van Rossum, <guido@python.org> wrote:
>
>> Trust me, the PEP authors are well aware. If we hadn't been from the
>> outset, a hundred different proposals to "deal" with this would have. And
>> many of those proposals actually made it into the list of rejected ideas.
>> Moreover, we rewrote a huge portion of the PEP from scratch as a result
>> (everything from Abstract up to the entire Rationale and Goals section).
>>
>> Apart from your insistence that we "acknowledge" an "inconsistency", your
>> counter-proposal is not so different from the others.
>>
>
> Right, there are several ways the PEP could be adjusted so that assignment
> target syntax and pattern matching syntax had consistent semantics whenever
> they share syntax, just as other name binding syntaxes are already strict
> subsets of the full assignment target syntax. I personally like "Use '?' as
> an explicit constraint expression prefix", but it's far from being the only
> possibility.
>
> But if we don't even agree that common syntax in a name binding context
> should either always mean the same thing, or else be a syntax error, then
> we're not going to agree that there's a problem to be solved in the first
> place.
>
> Let's agree to disagree on the best syntax for patterns
>>
>
> I think our disagreement is more fundamental than that, as I believe there
> should be a common metasyntax for imperative name binding (i.e. everything
> except function parameters) that all actual name binding contexts allow a
> subset of, while the PEP authors feel it's OK to treat pattern matching as
> a completely new design entity that only incidentally shares some common
> syntax with assignment targets.
>
> Prior to PEP 622, the apparent design constraint that I had inferred was
> implicitly met by the fact that all the imperative name binding operations
> accept a subset of the full assignment target syntax, so it's never
> actually come up before whether this is a real design goal for the
> language, or just a quirk of history.
>
> PEP 622 is forcing that question to be answered explicitly, as accepting
> it in its current form would mean telling me, and everyone else that had
> inferred a similar design concept, that we need to adjust our thinking.
>
> I'd obviously prefer it if the PEP chose a different syntax that avoided
> the semantic conflict with assignment for dotted names, but in the absence
> of that, I'd settle for the explicit statement that we're wrong and
> inferred a design principle that never actually existed.
>
> Cheers,
> Nick.
>
>
>
>
>>
>>

--
--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-change-the-world/>

> `np` analogue is quite a stretch and far-fetched, really.

I don't disagree. But `_` is a valid identifier so it shouldn't be
special. The solution is incredibly simple: allow repeated identifiers just
like in assignment so there is no need for a special wildcard symbol.

> ...<INTUITION ARGUMENT>...

I disagree but this is philosophical discussion which I would rather not go
down.

> ...<POINT ABOUT FUNCTION PARAMETERS>...

That's reasonable, although I would argue that a match is more like a for
loop (which allows arbitrary assignment) than a function definition. I do
understand your point though.

However, I still think the inability to match against a constant not in a
namespace is very annoying and could be overcome with some explicit
syntax. It's reasonable for this syntax to only allow NAME to be bound
(many places in the grammar do this, def, class, as, ...) but I haven't
seen a satisfactory reason why there *shouldn't* be support for NAME
constants; just reasons for why it's tricky.

You (or one of the authors) argue against `.constant` as a matching syntax
by saying: "..., it introduces strange-looking new syntax without making
the pattern syntax any more expressive." but this is obviously false. It
clearly does make the syntax more expressive, it allows one to express
something naturally without needing to create an auxiliary structure (or
the match syntax doesn't make the language more expressive either). Yes
namespaces are a great idea but as a consenting adult I should be free to
have constants that are not in a namespace. My constant may come in any
number of forms that are not conducive to simply "wrapping it in a
namespace", for example it may be used in other modules (so wrapping it
would require external changes) or it might be a closure variable and so
would require some explicit wrapping step.

Further, you argue elsewhere that the we shouldn't worry about a syntax
being strange because it's new so of course it's going to be different.
Yet for invoke this reasoning as a way to reject solutions to the NAME
constant issue. Pick one. (preferably the version that includes match
syntax and some strange new syntax for explicit constants because I super
want the match syntax).

Caleb Donovick

On Fri, Jul 31, 2020 at 12:40 AM Tobias Kohn <kohnt@tobiaskohn.ch> wrote:

> Hi Caleb,
>
> I will only answer to the second part, as the wildcard issue has
> been brought up and discussed time and again, and the `np`
> analogue is quite a stretch and far-fetched, really.
>
> One thing that stood out a bit to me as I feel to have seen it a
> couple of times is the question of intuition, so I will add a few
> more general thoughts to that...
>
> > [...] but it seems quite unintuitive to me [...]
>
> > [...] don't necessarily make it intuitively clear [...]
>
>
>
> Intuition (or lack thereof) has already been brought forward
> as an argument a couple of times. I would just like to briefly
> point out that there is no such thing as universal intuition in
> the field of programming. We all have different training,
> skills, preferences and experiences, which make up what
> we call 'intuition'. But what is intuitive is usually something
> completely different to C-programmer than to a Haskell- or
> Lisp-Programmer, say. And since pattern matching is really
> a new feature to be introduced to Python, a feature that can
> be seen in different lights, there is no 'Python-Programmer
> intuition' that would apply in this case.
>
> As for beginners, virtually every part of programming is
> unintuitive at first. Even something innocuous-looking like
> assignment is often reason for confusion because `3 + 4 = x`
> would probably be more 'intuitive'. But there is good reason
> with regards to the bigger picture to stick to `x = 3 + 4`.
>
> A Python-programmer (at any level) not familiar with pattern
> matching will most likely not understand all subtlety of the
> syntax---but this is alos true of features like `async` or the
> `/` in parameters, say. I would argue, though, that the clear
> choice of keywords allow anyone to quickly look pattern
> matching up and get informed on what it does. So, we do
> not need to come with something that is entirely 'intuitive'
> and 'self-evident'. But by sticking to common convention
> like `_` as wildcard, we can help quickly build the correct
> intuition.
>
>
> In your examples, for instance, it is perfectly obvious to me
> that you cannot directly assign to attributes and it would in
> fact look very weird to my eyes if you could. Your use case
> is quite similar to initialisers and you are arguing that you
> would like being able to write:
> ```
> *class* Point:
> *def* __init__(self, self.x, self.y):
> *pass*
> ```
> rather than the more verbose:
> ```
> *class* Point:
> *def* __init__(self, x, y):
> self.x, self.y = x, y
> ```
> I do not think that this would be a good idea for either
> parameters or patterns. After all, pattern matching is
> **not** assignment, even though it is related to it, of
> course.
>
> Kind regards,
> Tobias
>
>
>
> Quoting Caleb Donovick <donovick@cs.stanford.edu>:
>
> Adding this feature would be a giant quality of life improvement for me
> and I really hope it succeeds. So I have been trying to keep up on the
> debate in this and related thread.
>
> While I do want this feature, I agree with a lot of the issues people are
> raising.
>
> First I agree that _ should not be the wildcard symbol. Or rather the
> hobgoblins in my mind think that if _ is to be the wildcard symbol it would
> be more consistent with assignment if it was bound to the last value it was
> matched with (as should other repeated identifiers) e.g.,
>
> match pt:
> case (x, _, _):
> assert _ == pt[2]
>
>
> I understand the authors rationalize the decision based on conventions
> with the gettext module. I find these arguments very unconvincing. It's
> like saying the identifier np should be forbidden from appearing in cases
> because it's frequently used as the name of numpy. If there is to be a
> wildcard symbol (that does not bind and is repeatable) it should not be a
> valid identifier.
>
> Second, the distinction between a capture and constant value pattern
> should be more explicit. I don't have any great insight into the color of
> the shed beyond the numerous suggestions already made (name=, ?name,
> etc...), but it seems quite unintuitive to me that I can't capture into a
> namespace nor match a constant without a namespace. It is also unclear to
> me why it would be so terrible to add a new token or abuse an existing one.
>
> > Honestly, it doesn't help the case for `?` that it's been proposed as a
> mark for both capture patterns and value patterns (by different people,
> obviously :-).
>
> I agree that most of the proposed sheds don't necessarily make it
> intuitively clear what is a capture variable vs what is a constant.
> However they do give the programmer the ability to choose.
>
> For example if I want to modify the motivating example from the PEP
> slightly to copy attributes from one point to another I can't express it
> concisely:
>
> def update_point_3d(p: Point3d, pt):
> match pt:
> case (x, y):
> p.x, p.y = x, y
> case Point2d(x, y):
> p.x, p.y = x, y
> ...
>
>
>
> (Okay I could have just called the original make_point_3d and unpacked the
> results but it would require the creation of an unnecessary temporary.)
>
> However if the capture was explicit and any valid target could be used as
> a capture variable then I could express this cleanly:
>
> def update_point_3d(p: Point3d, pt):
> match pt:
> case (p.x=, p.y=):
> pass
> case Point2d(p.x=, p.y=):
> pass
> ...
>
>
>
> - Caleb Donovick
>
>
>
>
>
> _______________________________________________
> 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/YEHZ4W6CLHMHZJHVO6MZYF7VSL3ZNYFU/
> Code of Conduct: http://python.org/psf/codeofconduct/
>

Your point about wanting a way to use an unqualified name as a value
pattern is not unreasonable, and as you may recall we had an elegant
solution in version 1 of the PEP: a leading dot. However that was booed
away by the critics, and there has been no consensus (not even close) on
what to do instead.

Any solution that involves special markup (like bringing back the leading
dot, or backticks, or a question mark, or any other sigil) can easily be
added in a future version of Python.

There is one solution that I personally find acceptable but which found
little support from the other PEP authors. It is a rule also adopted by
Scala. This is to make it so that any identifier starting with a capital
letter (possibly preceded by one or more underscores) is a value pattern. I
note that in Scala, too, this is different in patterns than elsewhere in
the language: Scala, like Python, allows identifiers starting with a
capital letter to be assigned in other contexts -- just not in patterns. It
also uses roughly the same *conventions* for naming things as PEP 8
(classes Capitalized, constants UPPERCASE, variables and methods
lowercase). I also note that Scala allows backticks as another way to force
interpretation as a value pattern (though apparently it's not used much for
this purpose).

Finally I note that some human languages don't distinguish between
lowercase and uppercase (IIUC the CJK languages fall in this category). I
don't know what conventions users writing Python using identifiers in their
native language use to distinguish between constants and variables, but I
do know that they still use the Latin alphabet for keywords, builtins,
standard library names, and many 3rd party library names. This is why I
gave my proposed rule as "starting with a capital letter" and not as "not
starting with a lowercase letter", so that `case ?????:` will bind the
name ?????
instead of looking up that name; these seem the more useful semantics. If a
Japanese user wanted to look up that name they could write `HELLO = ?????`
followed by `case HELLO:`. (Of course, Latin-using users can do the same
thing if they have a name starting with a lowercase letter that they want
to use as a value pattern.)

Unfortunately we cannot leave the Capitalized rule to a future version of
Python, since the PEP as written interprets `case HELLO:` as a capture
pattern. (A compromise would be to disallow Capitalized identifiers
altogether, leaving the door open for a decision either way in the future.
But in that case I'd rather press for just instituting the rule now.)

About `_` enough has been written already.

On Sun, Aug 2, 2020 at 6:44 PM Caleb Donovick <donovick@cs.stanford.edu>
wrote:

> > `np` analogue is quite a stretch and far-fetched, really.
>
> I don't disagree. But `_` is a valid identifier so it shouldn't be
> special. The solution is incredibly simple: allow repeated identifiers just
> like in assignment so there is no need for a special wildcard symbol.
>
> > ...<INTUITION ARGUMENT>...
>
> I disagree but this is philosophical discussion which I would rather not
> go down.
>
> > ...<POINT ABOUT FUNCTION PARAMETERS>...
>
> That's reasonable, although I would argue that a match is more like a for
> loop (which allows arbitrary assignment) than a function definition. I do
> understand your point though.
>
> However, I still think the inability to match against a constant not in a
> namespace is very annoying and could be overcome with some explicit
> syntax. It's reasonable for this syntax to only allow NAME to be bound
> (many places in the grammar do this, def, class, as, ...) but I haven't
> seen a satisfactory reason why there *shouldn't* be support for NAME
> constants; just reasons for why it's tricky.
>
> You (or one of the authors) argue against `.constant` as a matching syntax
> by saying: "..., it introduces strange-looking new syntax without making
> the pattern syntax any more expressive." but this is obviously false. It
> clearly does make the syntax more expressive, it allows one to express
> something naturally without needing to create an auxiliary structure (or
> the match syntax doesn't make the language more expressive either). Yes
> namespaces are a great idea but as a consenting adult I should be free to
> have constants that are not in a namespace. My constant may come in any
> number of forms that are not conducive to simply "wrapping it in a
> namespace", for example it may be used in other modules (so wrapping it
> would require external changes) or it might be a closure variable and so
> would require some explicit wrapping step.
>
> Further, you argue elsewhere that the we shouldn't worry about a syntax
> being strange because it's new so of course it's going to be different.
> Yet for invoke this reasoning as a way to reject solutions to the NAME
> constant issue. Pick one. (preferably the version that includes match
> syntax and some strange new syntax for explicit constants because I super
> want the match syntax).
>
> Caleb Donovick
>
> On Fri, Jul 31, 2020 at 12:40 AM Tobias Kohn <kohnt@tobiaskohn.ch> wrote:
>
>> Hi Caleb,
>>
>> I will only answer to the second part, as the wildcard issue has
>> been brought up and discussed time and again, and the `np`
>> analogue is quite a stretch and far-fetched, really.
>>
>> One thing that stood out a bit to me as I feel to have seen it a
>> couple of times is the question of intuition, so I will add a few
>> more general thoughts to that...
>>
>> > [...] but it seems quite unintuitive to me [...]
>>
>> > [...] don't necessarily make it intuitively clear [...]
>>
>>
>>
>> Intuition (or lack thereof) has already been brought forward
>> as an argument a couple of times. I would just like to briefly
>> point out that there is no such thing as universal intuition in
>> the field of programming. We all have different training,
>> skills, preferences and experiences, which make up what
>> we call 'intuition'. But what is intuitive is usually something
>> completely different to C-programmer than to a Haskell- or
>> Lisp-Programmer, say. And since pattern matching is really
>> a new feature to be introduced to Python, a feature that can
>> be seen in different lights, there is no 'Python-Programmer
>> intuition' that would apply in this case.
>>
>> As for beginners, virtually every part of programming is
>> unintuitive at first. Even something innocuous-looking like
>> assignment is often reason for confusion because `3 + 4 = x`
>> would probably be more 'intuitive'. But there is good reason
>> with regards to the bigger picture to stick to `x = 3 + 4`.
>>
>> A Python-programmer (at any level) not familiar with pattern
>> matching will most likely not understand all subtlety of the
>> syntax---but this is alos true of features like `async` or the
>> `/` in parameters, say. I would argue, though, that the clear
>> choice of keywords allow anyone to quickly look pattern
>> matching up and get informed on what it does. So, we do
>> not need to come with something that is entirely 'intuitive'
>> and 'self-evident'. But by sticking to common convention
>> like `_` as wildcard, we can help quickly build the correct
>> intuition.
>>
>>
>> In your examples, for instance, it is perfectly obvious to me
>> that you cannot directly assign to attributes and it would in
>> fact look very weird to my eyes if you could. Your use case
>> is quite similar to initialisers and you are arguing that you
>> would like being able to write:
>> ```
>> *class* Point:
>> *def* __init__(self, self.x, self.y):
>> *pass*
>> ```
>> rather than the more verbose:
>> ```
>> *class* Point:
>> *def* __init__(self, x, y):
>> self.x, self.y = x, y
>> ```
>> I do not think that this would be a good idea for either
>> parameters or patterns. After all, pattern matching is
>> **not** assignment, even though it is related to it, of
>> course.
>>
>> Kind regards,
>> Tobias
>>
>>
>>
>> Quoting Caleb Donovick <donovick@cs.stanford.edu>:
>>
>> Adding this feature would be a giant quality of life improvement for me
>> and I really hope it succeeds. So I have been trying to keep up on the
>> debate in this and related thread.
>>
>> While I do want this feature, I agree with a lot of the issues people
>> are raising.
>>
>> First I agree that _ should not be the wildcard symbol. Or rather the
>> hobgoblins in my mind think that if _ is to be the wildcard symbol it would
>> be more consistent with assignment if it was bound to the last value it was
>> matched with (as should other repeated identifiers) e.g.,
>>
>> match pt:
>> case (x, _, _):
>> assert _ == pt[2]
>>
>>
>> I understand the authors rationalize the decision based on conventions
>> with the gettext module. I find these arguments very unconvincing. It's
>> like saying the identifier np should be forbidden from appearing in cases
>> because it's frequently used as the name of numpy. If there is to be a
>> wildcard symbol (that does not bind and is repeatable) it should not be a
>> valid identifier.
>>
>> Second, the distinction between a capture and constant value pattern
>> should be more explicit. I don't have any great insight into the color of
>> the shed beyond the numerous suggestions already made (name=, ?name,
>> etc...), but it seems quite unintuitive to me that I can't capture into a
>> namespace nor match a constant without a namespace. It is also unclear to
>> me why it would be so terrible to add a new token or abuse an existing one.
>>
>> > Honestly, it doesn't help the case for `?` that it's been proposed as a
>> mark for both capture patterns and value patterns (by different people,
>> obviously :-).
>>
>> I agree that most of the proposed sheds don't necessarily make it
>> intuitively clear what is a capture variable vs what is a constant.
>> However they do give the programmer the ability to choose.
>>
>> For example if I want to modify the motivating example from the PEP
>> slightly to copy attributes from one point to another I can't express it
>> concisely:
>>
>> def update_point_3d(p: Point3d, pt):
>> match pt:
>> case (x, y):
>> p.x, p.y = x, y
>> case Point2d(x, y):
>> p.x, p.y = x, y
>> ...
>>
>>
>>
>> (Okay I could have just called the original make_point_3d and unpacked
>> the results but it would require the creation of an unnecessary temporary.)
>>
>> However if the capture was explicit and any valid target could be used as
>> a capture variable then I could express this cleanly:
>>
>> def update_point_3d(p: Point3d, pt):
>> match pt:
>> case (p.x=, p.y=):
>> pass
>> case Point2d(p.x=, p.y=):
>> pass
>> ...
>>
>>
>>
>> - Caleb Donovick
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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/YEHZ4W6CLHMHZJHVO6MZYF7VSL3ZNYFU/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> _______________________________________________
> 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/RQDWPDYU4ZFXHI6RJ3AGDJUHI5LGLHSV/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


--
--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-change-the-world/>

On 2020-08-03 05:21, Guido van Rossum wrote:
> Your point about wanting a way to use an unqualified name as a value
> pattern is not unreasonable, and as you may recall we had an elegant
> solution in version 1 of the PEP: a leading dot. However that was booed
> away by the critics, and there has been no consensus (not even close) on
> what to do instead.
>
> Any solution that involves special markup (like bringing back the
> leading dot, or backticks, or a question mark, or any other sigil) can
> easily be added in a future version of Python.
>
> There is one solution that I personally find acceptable but which found
> little support from the other PEP authors. It is a rule also adopted by
> Scala. This is to make it so that any identifier starting with a capital
> letter (possibly preceded by one or more underscores) is a value
> pattern. I note that in Scala, too, this is different in patterns than
> elsewhere in the language: Scala, like Python, allows identifiers
> starting with a capital letter to be assigned in other contexts -- just
> not in patterns. It also uses roughly the same *conventions* for naming
> things as PEP 8 (classes Capitalized, constants UPPERCASE, variables and
> methods lowercase). I also note that Scala allows backticks as another
> way to force interpretation as a value pattern (though apparently it's
> not used much for this purpose).
>
[snip]
A thought occurred to me. By default, the current rules of the PEP could
apply, but why not allow prefixing with "as" for a capture and "is" for
a value?

Yes, I know, comparison of the values is not by identity, but "is" is a
short keyword that already exists and matches up with "as".


(After looking back through the thread it looks like Rob Cliffe has
already had the same idea.)
_______________________________________________
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/XVAJ76OOVFT3RJXDJH3BRNEHOFS7PAJS/
Code of Conduct: http://python.org/psf/codeofconduct/

On 03/08/2020 17:37, MRAB wrote:
> [snip]
> A thought occurred to me. By default, the current rules of the PEP
> could apply, but why not allow prefixing with "as" for a capture and
> "is" for a value?
>
> Yes, I know, comparison of the values is not by identity, but "is" is
> a short keyword that already exists and matches up with "as".
>
What about 'match'?  Not as short, but fairly intuitive:

    case (x, y, match Z):
        print(f'A point whose z-coordinate equals {Z}')
_______________________________________________
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/TXMR3IVHSKOLMNGUGSGLJSULY4FFHSBW/
Code of Conduct: http://python.org/psf/codeofconduct/

On Thu, 16 Jul 2020 at 19:09, Richard Damon <Richard@damon-family.org> wrote:
> One question that comes to mind, does match NEED a colon at the end of it? If it didn’t have the colon, it wouldn’t need the indent for the following lines.


Or something like

match t case ("rect", real, imag):
return complex(real, imag)
case ("polar", r, phi):
return complex(r * cos(phi), r * sin(phi))
else:
pass



--
Kind regards,

Stefano Borini
_______________________________________________
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/G6HNAS4TMH6DY6QTAYXUZJK5GIRI3MC5/
Code of Conduct: http://python.org/psf/codeofconduct/

Hi Larry,

You are right that just dismissing intuition is wrong.  I should have
been more careful with my wording or explain them better, and I would
like to apologise if my response came across as too strong in this
regard.

The actual problem that I see is that we have different
cultures/intuitions fundamentally clashing here.  In particular, so
many programmers welcome pattern matching as an "extended switch
statement" and find it therefore strange that names are binding and
not expressions for comparison.  Others argue that it is at odds with
current assignment statements, say, and question why dotted names are
_/not/_ binding.  What all groups seem to have in common, though, is
that they refer to _/their/_ understanding and interpretation of the
new match statement as 'consistent' or 'intuitive'---naturally
pointing out where we as PEP authors went wrong with our design.

But here is the catch: at least in the Python world, pattern matching
as proposed by this PEP is an unprecedented and new way of approaching
a common problem.  It is not simply an extension of something already
there.  Even worse: while designing the PEP we found that no matter
from which angle you approach it, you will run into issues of seeming
'inconsistencies' (which is to say that pattern matching cannot be
reduced to a 'linear' extension of existing features in a meaningful
way): there is always something that goes fundamentally beyond what is
already there in Python.  That's why I argue that arguments based on
what is 'intuitive' or 'consistent' just do not make sense _/in this
case/_.  I think the discussion on this mailing list with the often
contradictory views, proposals, and counter-proposals more than makes
my point.

As for your argument that it looks like calling a function or creating
an object: I tried to explain a little while ago that you'd be well
advised to rather approach it as something similar to a function
_/definition/_.  After all, the part after `def` in `def foo(a, b):`
also looks like a function call!  But nobody seems to mind this
similarity in syntax there!  And the target in `(a, b) = c` looks like
a tuple constructor, although it actually is the exact opposite.

Finally, I completely agree that intuition is informed by experience
and serving us very well.  The first part of this, however, is also to
say that intuition is malleable thing!  And experience from other
programming languages who took the leap to having pattern matching
shows that it quickly becomes a quite intuitive and easy to use feature.

Cheers,
Tobias

P.S. Please excuse my late reply; I am currently on vacation.

Quoting Larry Hastings <larry@hastings.org>:

>  
> On 7/31/20 12:36 AM, Tobias Kohn wrote:
>
>> And since pattern matching is really
>> a new feature to be introduced to Python, a feature that can
>> be seen in different lights, there is no 'Python-Programmer
>> intuition' that would apply in this case.
>
> It's not fair to say "intuition doesn't apply because it's new
> syntax".  There are plenty of examples of intuition serving a Python
> programmer well when encountering new syntax.  A Python programmer's
> intuition is informed by existing syntax and conventions in the
> language.  When they see a new construct, its similarity to existing
> constructs can make understanding the new syntax quite intuitive
> indeed.
>
> Take for example list comprehensions.  Python 1 programmers hadn't seen
>
>> a = [x for x in y]
>
> But they knew what square brackets meant in that context, it meant
> "creates a new list".  And they knew what "for x in y" meant, that
> meant iteration.  Understanding those separate two concepts, a
> Python 1 programmer would be well on their way to guessing what the
> new syntax meant--and they'd likely be right.  And once they
> understood list comprehensions, the first time they saw generator
> expressions and set and dict comprehensions they'd surely intuit
> what those did immediately.
>
> The non-intuitiveness of PEP 622, as I see it, is that it
> repurposes what looks like existing Python syntax but frequently has
> wholly different semantics.  For example, a "class pattern" looks
> like it's calling a function--perhaps instantiating an object?--but
> the actual semantics and behavior is very different.  Similarly, a
> "mapping pattern" looks like it's instantiating a dict, but it does
> something very different, and has unfamiliar and seemingly arbitrary
> rules about what is permitted, e.g. you can't use full expressions
> or undotted-identifiers when defining a key.  Add the "capture
> pattern" to both of these, and a Python programmer's intuition about
> what this syntax traditionally does will be of little help when
> encountering a PEP 622 match statement for the first time.
>
> Cheers,
>
>  
>
> //arry/

On 7/30/20 8:35 AM, Rob Cliffe via Python-Dev wrote:

> The debate is still going on as to whether "capture" variables should be
> marked...
I don't think the PEP authors are debating it any more. Quite frankly,
I wish they would present to the SC and get accepted so we can get
Pattern Matching added to 3.10. :)

--
~Ethan~
_______________________________________________
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/PGEVEI2W7L32FFCLFOWGFRANMBZHPILQ/
Code of Conduct: http://python.org/psf/codeofconduct/