Hello, On Thu, 12 Nov 2020 09:55:10 -0800 Guido van Rossum wrote:

The position of PEP 622/634/535/636 authors is clear: we see this as a necessary feature to support using enums (e.g. Color.RED) or constants defined in other modules (e.g. re.I) when simple switch functionality is being migrated from literals (e.g. case 404) to named constants (e.g. case HTTPStatus.NOT_FOUND). Bothering users with the technicality of needing to use '==' here is a big usability hit.

As was pointed out many times on the mailing list, there's a very obvious way around needing to use '==' there. It's explicitly marking capturing terms in case's: match foo: case ("foo", >val1): ... case ("bar", >val2): ... Besides solving the chore of needing "==" prefix, it allows for the following benefits: 1. Much more intuitive for beginners. (If Python adopts it, I see other "user-friendly" languages adopting the same pattern in the coming decades). 2. Upholds the rights of people who see "match" as glorified "switch" statement, and not keen on it doing assignments behind their backs. (The topic which was recently mentioned on the list.) 3. Solves discrepancy with cases like: # Why is this possible? obj.foo, obj.bar = val # And this is not? match val: case obj.foo, obj.bar: 4. Most uses of pattern matching known to people ("mental background") are from languages with strong culture of immutability. And that's why those languages manage to do it without much of sigils. For a language with a looming conceptual debt of not having constness/immutability in the core language semantics (aka, "Please move this subtopic to a subject that doesn’t have “PEP 622” in its topic." "https://mail.python.org/archives/list/python-dev@python.org/message/GFMOZ6XF... ), the idea to mark capturing terms, seems like a very smart way to route around this conceptual deficiency, yet improve readability. pp.3 and 4 also explain why it's obj.foo, obj.bar = val but would be: match val: case >obj.foo, >obj.bar: With destructuring assignment, the *assignment* operator is right there, and terms are on the left side of it, so it's all clear to a reader. With "match", there's no obvious assignment operator, and terms can be also used as values, so adding explicit "assign here" marker looks like rather natural idea to keep a reader in loop of what's happening there. [] -- Best regards, Paul mailto:pmiscml@gmail.com

On Thu, Nov 12, 2020 at 09:40:02PM +0300, Paul Sokolovsky wrote:

match foo: case ("foo", >val1): ... case ("bar", >val2): ...

1. Much more intuitive for beginners. (If Python adopts it, I see other "user-friendly" languages adopting the same pattern in the coming decades).

I think you and I have a very different concept of "intuitive for beginners" here. I don't think that using the *greater than symbol* as a sigil for assignment would have been "intuitive" to me as a beginner, or anyone I have helped teach over the years. To me, that statement clearly and obviously could only mean one possible thing: * match a two-sequence where the first item equals "foo" and the second is greater than `val1`; (and similarly for the second case statement). Are there any other languages that use `>` as a prefix sigil to indicate assignment? If we were to use a sigil to represent binding, surely `=` would make more sense than `>`.

2. Upholds the rights of people who see "match" as glorified "switch" statement,

There is no right for people to dictate that syntax must support their misapprehensions about language features. Or for that matter, no right to dictate *anything* about syntax. There is no universal human right to dictate Python syntax. The best you have is the privilege to attempt to persuade others to support your preference, and for the Steering Council to be swayed by your arguments and/or the popular support for your preference.

and not keen on it doing assignments behind their backs. (The topic which was recently mentioned on the list.)

How is it doing assignments behind your back? The syntax is clear: a name is a binding pattern. That is as much an explicitly assignment statement as import, for, with...as, def or class. This is an assignment "behind your back": def sneaky_assignment(): global x x = 999 sneaky_assignment() There's nothing in the call to `sneaky_assignment` to hint that it assigns a value to the global `x`. Pattern matching is nothing like that: all binding patterns are explicit, all you need is to get past the misapprehension that pattern matching is a switch statement (it isn't!) and it will be clear as daylight: case 1, x: pass Of course x gets assigned to. It's a binding pattern. import sys Of course sys gets assigned to. It's an import.

3. Solves discrepancy with cases like:

# Why is this possible? obj.foo, obj.bar = val

# And this is not? match val: case obj.foo, obj.bar:

I agree with this. I think it is surprising that unqualified names are binding patterns but qualified names are not. That difference gives me pause. But using `>` as an assignment sigil is surely worse than the problem you hope to solve with it. -- Steve

Paul Sokolovsky wrote:

Use punctuation ("sigils") to mark as-binding terms. This choice still seems to be under-considered. (As in: it doesn't seem like many people, including the PEP authors, tried to say "indeed, what if?" and feel thru it. I mean, try really hard. I trust the "gang of 4" spent maybe whole few hours on that and delivered "no" to all us. It's still not the same as dozens of people trying it over a few months).

To anyone actually wondering how much time and mental energy we’ve spent on a particular issue: please take a look at our tracker before guessing “maybe whole few hours”: - Issue #1(!), April, 29 comments: https://github.com/gvanrossum/patma/issues/1 - Issue #90, June, 84 comments: https://github.com/gvanrossum/patma/issues/90 - Issue #92, June, 33 comments: https://github.com/gvanrossum/patma/issues/92 - Issue #105, June, 17 comments: https://github.com/gvanrossum/patma/issues/105 - Issue #143, August, 7 comments: https://github.com/gvanrossum/patma/issues/143 (I won't judge anyone for skimming a bit; it's a *lot* of discussion. Do note, though, that for months I was one of the proponents of store sigils like `?` until I was eventually convinced otherwise.) That's also not counting side-discussions in other issues, countless mailing list threads, two competing PEPs that make many of the same choices, a video call with the SC, etc. I'll also add, for anyone considering choosing yet another ASCII symbol off their keyboard and proposing it as a “novel”, “intuitive” marker: one problem with most of the hastily suggested adornments are that they do not nest very well, for even simple cases. Further, the fact that constructions like `p = Point(x, y)` look exactly the same as deconstructions like `case Point(x, y):` is absolutely intentional (which touches back on Guido’s “rhyme” comment last night). Very briefly, compare the current syntax: ``` case first, *middle, last: rebuilt = first, *middle, last case {"key": value, **rest}: rebuilt = {"key": value, **rest} case Point(x=a, y=b): rebuilt = Point(x=a, y=b) ``` with (using your own syntactic flavor): ``` case >first, *>middle, >last: rebuilt = first, *middle, last case {"key": >value, **>rest}: rebuilt = {"key": value, **rest} case Point(x=>a, y=>b): rebuilt = Point(x=a, y=b) ``` (I had to stop and think *hard* where exactly the `>` should go in `*middle` and `**rest`. I'm not confident I made the correct guess, either.)

I *hope* this was a typo! If case Point(x=a, y=b): assigns to a and b (instead of x and y, as in a normal call), then that is ... going to be very easy for me to forget, and to miss even when I'm aware of it. -jJ

On 11/13/2020 1:48 PM, Joao S. O. Bueno wrote:

On Fri, 13 Nov 2020 at 17:36, Jim J. Jewett mailto:jimjjewett@gmail.com> wrote:

I *hope* this was a typo!  If

    case Point(x=a, y=b):

assigns to a and b (instead of x and y, as in a normal call), then that is ... going to be very easy for me to forget, and to miss even when I'm aware of it.

No typo -  this is _precisely_what the main proposal on PEPs 634, 635 and 636 is suggesting, and tha PEP 642 is trying to avoid.

And the claim is, that there are people that think this is a good idea❓❓ And are actually proposing to add it to Python❓

Here it is working as is  on my Python with PEP 622 build:

``` Python 3.10.0a0 (heads/patma:1ba56a003b, Aug  6 2020, 02:00:58) Type 'copyright', 'credits' or 'license' for more information IPython 7.17.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: fromdataclassesimportdataclass

In [2]: @dataclass   ...: classPoint:   ...:     x: float   ...:     y: float   ...:

In [3]: defget_coords(p):   ...:     match p:   ...:         case Point(x=a, y=b):   ...: returna, b   ...:         case _:   ...: raiseTypeError()   ...:

In [4]: get_coords(Point(3, 4)) Out[4]: (3, 4)

```

-jJ

On 14/11/20 9:33 am, Jim J. Jewett wrote:

I *hope* this was a typo! If

case Point(x=a, y=b):

assigns to a and b (instead of x and y, as in a normal call), then that is ... going to be very easy for me to forget, and to miss even when I'm aware of it.

I don't think it is a typo, unfortunately. I share this concern, and it's one of the reasons I would prefer assignments to be explicitly marked. With case Point(x=?a, y=?b): then if you get it wrong and write case Point(?a=x, ?b=y): at least you'll get a syntax error. -- Greg

On 14/11/20 7:45 am, Brandt Bucher wrote:

with (using your own syntactic flavor): ``` case >first, *>middle, >last: rebuilt = first, *middle, last case {"key": >value, **>rest}: rebuilt = {"key": value, **rest} case Point(x=>a, y=>b): rebuilt = Point(x=a, y=b)

I think this is a case where syntax matters. To my eyes this looks far less confusing: case ?first, *?middle, ?last: rebuilt = first, *middle, last case {"key": ?value, **?rest}: rebuilt = {"key": value, **rest} case Point(x=?a, y=?b): rebuilt = Point(x=a, y=b)

(I had to stop and think *hard* where exactly the `>` should go in `*middle` and `**rest`.

There's a simple rule -- the "?" goes directly in front of the thing being assigned. You're assigning to 'middle', not '*middle', so it's '*?middle', not '?*middle'. I know the same rule applies whatever sigil is being used, but to my way of thinking, '>' is too easily confused with a comparison operator. Also it's tempting to interpret '=>' as a single token, which accidentally happens to make sense here, but could mislead people into writing '*=>middle' instead of '*>middle'. -- Greg

On Sat, Nov 14, 2020 at 7:54 AM Nick Coghlan wrote:

On Sat, 14 Nov 2020 at 09:51, Greg Ewing wrote:

...

On 14/11/20 7:45 am, Brandt Bucher wrote:

...

with (using your own syntactic flavor): ``` case >first, *>middle, >last: rebuilt = first, *middle, last case {"key": >value, **>rest}: rebuilt = {"key": value, **rest} case Point(x=>a, y=>b): rebuilt = Point(x=a, y=b)

I think this is a case where syntax matters. To my eyes this looks far less confusing:

case ?first, *?middle, ?last: rebuilt = first, *middle, last case {"key": ?value, **?rest}: rebuilt = {"key": value, **rest} case Point(x=?a, y=?b): rebuilt = Point(x=a, y=b)

Based on the discussion in this thread, v3 of PEP 642 is going to propose spelling these as:

case first, *middle, last: rebuilt = first, *middle, last case {"key" as value, **rest}: rebuilt = {"key": value, **rest} case Point(x as a, y as b): rebuilt = Point(x=a, y=b)

I'm in agreement with the PEP 634 authors that we want to keep sequence pattern matching consistent with iterable unpacking as far as name binding is concerned. Mapping patterns and class patterns are both completely new though, and I think the readability problem there is quite similar to the one that existed with walrus patterns in PEP 622, and thus amenable to a similar solution (i.e. spell the capture patterns for those cases with `as`, not `:` or `=`).

FWIW, I'd like to add my +1 to usage of "as" for spelling class capture patterns. This is by far the clearest and easiest to read form I've seen thus far, and I suspect that it would be the easiest to explain to users already familiar with usage of "as" from other areas in Python. A new feature being as distinguishable as possible and easy to explain to existing users is very important in my book, and based on the responses, I think that the current "=" form used in PEP 634 for matching class patterns would be substantially more difficult for users to mentally parse and understand compared to "as". It's also worth considering new Python users that might have general OO experience but not with robust pattern matching (e.g. Java-heavy backgrounds). I could definitely see "case Point(x=a, y=b):" being confused for instantiation, whereas usage of "as" makes it more clear that something else is happening (hopefully leading them to search around for more info about Python pattern matching).

On Sun, Nov 15, 2020 at 1:56 AM Chris Angelico wrote:

On Sun, Nov 15, 2020 at 4:28 PM Kyle Stanley wrote:

...

FWIW, I'd like to add my +1 to usage of "as" for spelling class capture

patterns. This is by far the clearest and easiest to read form I've seen thus far, and I suspect that it would be the easiest to explain to users already familiar with usage of "as" from other areas in Python. A new feature being as distinguishable as possible and easy to explain to existing users is very important in my book, and based on the responses, I think that the current "=" form used in PEP 634 for matching class patterns would be substantially more difficult for users to mentally parse and understand compared to "as".

...

It's also worth considering new Python users that might have general OO

experience but not with robust pattern matching (e.g. Java-heavy backgrounds). I could definitely see "case Point(x=a, y=b):" being confused for instantiation, whereas usage of "as" makes it more clear that something else is happening (hopefully leading them to search around for more info about Python pattern matching).

...

case Point(x=as a, y=as b):

That doesn't read well to me.

Or is there some other spelling of 'as' that makes better sense to you?

The post from Nick that I was primarily replying to used the following spelling: "case Point(x as a, y as b):".

On Sun., 15 Nov. 2020, 5:25 pm Guido van Rossum, wrote:

But Point(x as a) already has a meaning in PEP 634; it’s a positional argument captured in x *and* in a. (Previously spelled as Point(a := x). The phrase ‘as a’ can be added after any pattern to *also* capture it in ‘a’. More typically used as e.g.‘Pattern(x, y) as p’, which captures the first two fields in x and y, and the whole Point in p.

Indeed, the proposed change I'm contemplating for class matching would require that positional matching be opt-in rather than the default. The default would instead become to check that the named attributes exist, so "Pattern(x, y)" would be short for "Pattern(x=__, y=__)", and you'd have to write "Pattern(x, y, /)" instead to request positional arg matching. The default behaviour of class patterns would become a lot more like mapping patterns, but working off attribute names rather than keys. I think that will give an end result that offers the same capabilities as PEP 634, but the proof will be in the reference implementation update. Cheers, Nick.

Matching *should* look like instantiation ... case Point(2, 4) *should* mean "Does it match the object that Point(2, 4) would create?". case Point(2, y=4) is less crucial, because they *could* rewrite the call -- but why should they have to? Changing from constants, and case Point(x=a, y=b) suddenly means x is the already externally bound name and *a* is being assigned to, so it doesn't need to have been defined previously? What advantage can there be in re-using syntax to mean something opposite to what it normally does? Others have objected to both case Point(x as a) and case Point(a:=x) # I dislike it, but it isn't as bad as the raw = but I am missing the problem, other than the confusion binding always brings. To me, they do both seem to say "It matches the object that would be created by Point(x) for *some* x, and an example/witness x that works is now stored in a. If there is no way to resolve this, I would honestly prefer to require nested matching, vs using call signatures in a way opposite to their normal usage. -jJ

On 11/15/2020 11:18 PM, Stephen J. Turnbull wrote:

Jim J. Jewett writes:

...

What advantage can there be in re-using syntax to mean something opposite to what it normally does?

In math, it allows us to write "solve c = f(x) for x". That doesn't mean "bind c to the value f(x)", it means exactly the opposite. No problem here, I suppose. So

match p: case Point(x=a, y=b):

is a way of saying "solve p = Point(x=a, y=b) for a and b".

I understand your distaste for this syntax, but I see no problem in principle. It's a problem of programmer habits and the evident inconsistency with forms like "case Point(x=1, y=2)". This is especially true when a or b is already bound. Indeed. Mathematics never came up with separate symbols for equality and assignment. Neither did early programming languages. That was a source of confusion for many programmers.

Then someone invented == for equality comparison, and = for assignment, or alternately := for assignment and = for equality comparison.  Python now has the first three, many other languages only have one of the pairs. This reduced the confusion and resulting bugs, although some still happen. Linters help avoid them, and even some compilers emit warnings for possibly misused operators of those pairs. In mathematics, equality might be written a = b or b = a, transitively irrelevant. But I have never seen assignment in mathematics be anything but var = value, as in "let x = 3"  or "let x = <some constant or expression>". Maybe I'm just uninformed regarding current practice, but I do have a degree in mathematics, albeit somewhat dated at this point. So I also have a distaste for any syntax that puts an assignment target on the right, it seems like a step toward reintroducing confusion and bugs. The pattern match operator seems complex enough without (re-)introducing confusion regarding assignment operators. In your example "solve c = f(x) for x", that is not an assignment operator, but an equality comparison operator in an equation. Although I know a few exist, I'm not familiar with programs that do symbolic algebra, to know how they notate such instructions: most programming language do not do symbolic manipulations.  But note that your example is wordier than "let c = f(x)" which would be an assignment operation. And note that it _needs to be wordier_ to convey the proper mathematical semantics. At least, it did back when I was in math classes. Just because something is syntactically unambiguous, doesn't mean it makes a good user interface.

Glenn Linderman writes:

Mathematics never came up with separate symbols for equality and assignment.

Mathematics doesn't need them, until we come to an age where we do mathematics on algorithms. It's perfectly possible to do algebra interpreting "let x = 3" as an equation of the form "f(x) = g(x)" rather than an assignment.

In your example "solve c = f(x) for x", that is not an assignment operator, but an equality comparison operator in an equation.

But "=" is sugar, not syntax, in the "let" form, and although it is syntax in the "solve" form, in both cases it is the keyword "let" or "solve" that denotes assignment. So "solve c = f(x) for x" *can* be interpreted as an assignment to x.

But note that your example is wordier than "let c = f(x)" which would be an assignment operation. And note that it _needs to be wordier_ to convey the proper mathematical semantics.

Wordiness in defense of readability is no sin, at least not in Python. :-) In exactly the same way as you describe for the "solve" example, a destructuring pattern match is necessarily wordier than simple assignments to the component variables would be. So I don't see an issue here.

Just because something is syntactically unambiguous, doesn't mean it makes a good user interface.

I didn't (and don't) argue it does. I argue it works for me, and if it works for Guido too, I refuse to feel bad about that. ;-) If it doesn't work for a large majority of people who would use pattern matching in Python, who would want to destructure "Point(x=a,y=b)", it's bad UI. I don't know that's true yet, so I want to oppose false statements like "there's no analogy to this" (which is not quite what Jim said). Tastes differ, those differences are valid, and to some extent the majority rules here (although I've seen in the past that some folks are much better judges of *future* majorities than others! ;-) Steve

Hello, On Fri, 13 Nov 2020 18:45:55 -0000 "Brandt Bucher" wrote:

Paul Sokolovsky wrote:

...

Use punctuation ("sigils") to mark as-binding terms. This choice still seems to be under-considered. (As in: it doesn't seem like many people, including the PEP authors, tried to say "indeed, what if?" and feel thru it. I mean, try really hard. I trust the "gang of 4" spent maybe whole few hours on that and delivered "no" to all us. It's still not the same as dozens of people trying it over a few months).

To anyone actually wondering how much time and mental energy we’ve spent on a particular issue: please take a look at our tracker before guessing “maybe whole few hours”:

Thanks for the very useful response. (Which follows another useful from another PEP author, Tobias Kohn, https://mail.python.org/archives/list/python-dev@python.org/thread/FYGTU4RMZ...). Thanks gentlemen for still keeping up the discussion even if you went thru all those matter many times.

- Issue #1(!), April, 29 comments: https://github.com/gvanrossum/patma/issues/1 - Issue #90, June, 84 comments: https://github.com/gvanrossum/patma/issues/90 - Issue #92, June, 33 comments: https://github.com/gvanrossum/patma/issues/92 - Issue #105, June, 17 comments: https://github.com/gvanrossum/patma/issues/105 - Issue #143, August, 7 comments: https://github.com/gvanrossum/patma/issues/143

(I won't judge anyone for skimming a bit; it's a *lot* of discussion.

I have to admit that I didn't read thru it. And fairly speaking, my aim is not to argue with the PEP authors, but "raise awareness" of the implications of choices made by PEP634 (and that the choice made there is not the "absolute winner", but more and more look like a leap of faith among other viable choices.) Anyway, given that you even included the # of messages above, let me still do some homework and add to stats number of participants in the ticket thread above (as an indirect way to assess community outreach): 5 + 12 + 8 + 6 + 5 I'm not sure what to do with these numbers (doing max() perhaps?). It's clear that the discussions there are more active than on the mailing list.

Do note, though, that for months I was one of the proponents of store sigils like `?` until I was eventually convinced otherwise.)

That's another great answer! Given that PEP622 had 6 authors, it's pretty mathematically clear that there should have been proponents of all 3 load/store options, and I wondered who's who. []

I'll also add, for anyone considering choosing yet another ASCII symbol off their keyboard and proposing it as a “novel”, “intuitive” marker: one problem with most of the hastily suggested adornments are

I don't think the problem is "hastily suggested <foo>". The problem is more that: despite all your great and multiple considerations, finding a compromise among you 6, compressing it to a small paragraph of PEP635, with culminating sentence in it starting with "However, this is based on the misconception", which sets the tone very well - despite all this great work, there're still people who think that you didn't do fairness to the idea of marking the stores. A possible solution would have been to extend discussion of this option in PEP635, and start with considering what would be lost by *not* adopting that approach, instead of coloring it all in a dismissive tone from the start. I know that might have been hard. As we know, an "alternative" PEP 642 was spawned exactly out of rejection of additional information regarding "sigils for loads" idea: https://github.com/python/peps/pull/1564

that they do not nest very well, for even simple cases.

I propose to add a unary prefix operator (choices among ">", ">>", "->", "@", etc.) Those do nest well. Some are completely unambiguous.

Further, the fact that constructions like `p = Point(x, y)` look exactly the same as deconstructions like `case Point(x, y):` is absolutely intentional (which touches back on Guido’s “rhyme” comment last night).

I don't think that "exactly the same" is the right words, or expectations to have. For example, PEP622 used phrase "It would break the syntactic parallels of the current grammar". And that's the whole point: `case Point(>x, >y)` is exactly parallel to `p = Point(x, y)`! The only difference is that the bind-to terms (here, the variables) are explicitly marked. Consider if the language had a color as syntactic means. Then in `p = Point(x, y)`, x and y would be colored in one way, but in `case Point(x, y)` - in different way. But they would be exactly parallel, and maybe even "the same". Thankfully, we don't use colors as syntactic means. The closest device we have is punctuation, and that's where idea to use sigils come from.

Very briefly, compare the current syntax:

``` case first, *middle, last: rebuilt = first, *middle, last case {"key": value, **rest}: rebuilt = {"key": value, **rest} case Point(x=a, y=b): rebuilt = Point(x=a, y=b) ```

with (using your own syntactic flavor):

``` case >first, *>middle, >last: rebuilt = first, *middle, last case {"key": >value, **>rest}: rebuilt = {"key": value, **rest} case Point(x=>a, y=>b): rebuilt = Point(x=a, y=b) ```

(I had to stop and think *hard* where exactly the `>` should go in `*middle` and `**rest`. I'm not confident I made the correct guess, either.)

In my idea, ">" (or the like) would be a kind of low-precedence unary operator with only comma "," being of lower precedence. It would be written correspondingly, at the outermost level of the term, e.g.: case >first, >*middle, >last: rebuilt = first, *middle, last case {"key": >value, >**rest}: rebuilt = {"key": value, **rest} case Point(x = >a, y = >b): # Space is mandatory here, why I think ">" # alone would not be adopted. So, you say compare it with PEP634? But that's how I arrived here! Months after first reading initial PEP622 and being sleep-walked thru that option by it ("No other language use that option, so we don't want either" - "No, of course not, sir!") - I decide to think "what if", and write down something like the above. And I have to say you, it doesn't look that bad! It resolves a hard gripe I have with PEP622/634, that it can't do: MY_LOVELY_CONSTANT = 1 case MY_LOVELY_CONSTANT: But beyond that, it also makes clear to even kids what's being captured, and what's not. And just as we speak, real fun only starts. The echo just starts to reach the wider community which starts to think what stuff in PEP634 *really* means. https://mail.python.org/archives/list/python-dev@python.org/message/F66J72JU... is only a first in a wave of "d'oh" emails. Can't say I expect there would a zunami, but one can easily expect a long, persistent, not subsiding trickle of those. But not only novices (novices in Python, but also novices in pattern matching) are confused. In https://mail.python.org/archives/list/python-dev@python.org/message/Q2ARJULL... , a core Python developer publicly admits "it wasn't something that had previously occurred to me as a possible problem". I.e. he read PEPs all this time, got some issues with them (caused him to submit an "elaboration" PEP), but he didn't see *all* issues with them. Dear Brandt, please hang on with us, the wider Python community, as it starts to dawn on us. The real fun just begins. -- Best regards, Paul mailto:pmiscml@gmail.com

On Sat, 14 Nov 2020 at 01:59, Baptiste Carvello wrote:

Hi,

Le 12/11/2020 à 18:55, Guido van Rossum a écrit :

...

The position of PEP 622/634/535/636 authors is clear:

well, let me first emphasize that I did *not* mean to reopen the discussion on those PEPs, which explain and discuss their design choices thoroughly (even better since the rewrite, thanks for that). And I definitely did not mean to spawn another "mark capture or value" subthread… I thought "PEP 642 v2" in the thread title was explicit enough, should have been more cautious :-)

PEP 642 states as a design principle that parallelism between patterns and assignments should be kept as much as possible (let's not discuss this principle here). Thus, introducing different semantics for dotted names deserves a discussion in that PEP (by contrast, literal constraints need little discussion, because they have no semantics in assignments).

You're right, I had missed that I didn't mention attribute syntax specifically in https://www.python.org/dev/peps/pep-0642/#keeping-inferred-equality-constrai... The rationale is the same as it is in PEP 635: comparing against enum values is likely to be super common, and requiring the extra "==" sigils in that case at least arguably hinders readability rather than helping it. I actually find most of the predictions of likely usage patterns in PEP 635 entirely plausible - where I differ with the authors of that PEP is in whether or not we need to offer explicit override syntax for the cases where those predictions turn out to be wrong, rather than in our opinions of what the most common use cases are actually going to be.

...

we see this as a necessary feature to support using enums (e.g. Color.RED) or constants defined in other modules (e.g. re.I) when simple switch functionality is being migrated from literals (e.g. case 404) to named constants (e.g. case HTTPStatus.NOT_FOUND). Bothering users with the technicality of needing to use '==' here is a big usability hit.

Indeed, enums and other dotted constants are the heart of the matter. And I get your point about not making useful refactoring more difficult. Still it could make sense (in the philosophy of PEP 642, again) to defer the choice and see how strong the need is. What PEP 642 ends up proposing will be Nick Coghlan's call.

I opted to include the inferred equality constraints for attributes specifically to make the revised PEP 642 almost purely additive over PEP 634 - while v1 removed a lot of things (which raised several legitimate readability and usability concerns), the only things v2 outright removes are the inferred constraints for True and False (on grounds of ambiguity). The rest of the changes are now either new additions (explicit identity and equality constraints), changes in spelling (double-underscore vs single-underscore for wildcards), or slight changes in how constructs are defined (the inferred constraints for literals and attribute lookups get redefined as syntactic sugar for their explicit counterparts, rather than being first class constructs in their own right). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia