Walter Dörwald wrote:

This looks strange to me. In all other cases of variable lookup the global variable z would be found.

The next case assigns to z, making z local to whereis. This is consistent with python's existing scoping rules (for example, try rewriting this as the equivalent if-elif chain and you'll get the same error). It sounds like you want to add "global z" to the top of the function definition.

whereis(23) however works.

This branch is hit before the unbound local lookup is attempted.

On Thu, 2 Jul 2020 at 09:28, Matthias Bussonnier wrote:

It's still weird user experience as if you swap case .z and case z you don't get the Unbound error anymore. SO it can work w/o global.

For some value of work: if z comes before .z, the .z branch will never get evaluated, because the binding of z will take precedence, making the .z branch dead code. This is something I would expect linters to pick up on (eventually), or possibly the compiler itself. And if you don't put z first, anything that hits the .z branch will throw the UnboundLocalError. -Rob

On 2/07/20 4:54 am, Brandt Bucher wrote:

It sounds like you want to add "global z" to the top of the function definition.

Or more likely, change the last case to 'case _'. -- Greg

+1 Is there a reason, after all, why we should mark constant patterns as special, and not the opposite? On 02/07/2020 19:10, Walter Dörwald wrote:

On 1 Jul 2020, at 18:54, Brandt Bucher wrote:

...

Walter Dörwald wrote:

...

This looks strange to me. In all other cases of variable lookup the global variable z would be found.

The next case assigns to z, making z local to whereis. This is consistent with python's existing scoping rules (for example, try rewriting this as the equivalent if-elif chain and you'll get the same error). It sounds like you want to add "global z" to the top of the function definition.

...

whereis(23) however works.

This branch is hit before the unbound local lookup is attempted.

OK, understood.

However I still find the rule "dotted names are looked up" and "undotted names are matched" surprising and "case .constant" ugly.

A way to solve this would be to use "names at the top level are always looked up".

With this the constant value pattern:

    case .name:

could be written as:

    case name:

The capture pattern (of which there can only be one anyway) could then be written as:

    case object(name):

instead of

    case name:

Or we could use "matches are always done against a match object", i.e. the code from the example would look like this:

    from dataclasses import dataclass

    @dataclass     class Point:         x: int         y: int

    z = 42

    def whereis(point):         w = 23         match point as m:             case Point(0, 0):                 print("Origin")             case Point(0, m.y):                 print(f"Y={m.y}")             case Point(m.x, 0):                 print(f"X={m.x}")             case Point():                 print("Somewhere else")             case w:                 print("Not the answer")             case z:                 print("The answer")             case object(z):                 print(f"{z!r} is not a point")

Servus,    Walter

On Sat, Jul 4, 2020 at 12:48 AM Rob Cliffe via Python-Dev wrote:

Whoa!

I have an uneasy feeling about this PEP.

AFAIK the usual procedure for adding a new feature to Python is: An idea is raised and attracts some support. Someone sufficiently motivated writes a PEP. The PEP is thoroughly discussed. Eventually a consensus (or at least an "agree to differ" stalemate) is reached. The PEP is accepted (if it is). (Then and only then) Someone works on the implementation. etc.

However, PEP 622 only seems to have been presented to the Python community only *after* a well-developed (if not finalised) implementation was built. A fait accompli.

The PEP is still a draft and has not been accepted. Don't worry, the normal process is still happening :) Having a reference implementation is a HUGE help, because people can play around with it. There's a fork running an interactive playground so you can go right now and get a feel for the way the syntax works. The implementation has *not* been merged into the CPython trunk. It's not a fait accompli - it's a tool to help people evaluate the proposal (and all of the different variants of the proposal as it evolves). Speaking with my PEP Editor hat on, I would be *thrilled* if more proposals came with ready-to-try code. Only a very few have that luxury, and a lot of the debating happens with nothing but theory - people consider what they *think* they'd do, without actually being able to try it out and see if it really does what they expect. Having a reference implementation isn't necessary, of course, but it's definitely a benefit and not a downside. Also, there HAVE been proposals with full reference implementations that have ended up getting rejected; it's not a guarantee that it'll end up getting merged. Hope that lessens your fears a bit :) ChrisA

On Tue, 7 Jul 2020 at 15:04, Rob Cliffe via Python-Dev < python-dev@python.org> wrote:

I don't like the .name syntax (grit on Tim's monitor; does not suggest the meaning). [...] But I don't know what syntax (where necessary) to suggest.

+1(000)

I'm not keen on special treatment of the '_' variable, and would prefer to be able to use 'else:' after 'match'.

I used to be in this "camp", however, a (I think valid) point was raised that "else:" is not a (full) alternative. Due to the restriction on repeated names (e.g. Point(x, x) is illegal), if you want to "throw away" intermediate matches, you will have to either have to come up with new names (Point(unused_1, unused_2)) or use the "_" as currently instituted (Point(_, _)) and "else:" does not cover that insofar as I can tell. Would it be possible here to use a syntax/symbol that is illegal instead of _? I think this has been mooted but my favourite (so far) would be "?" so you have "case ?:" and "Point(?, ?)". Would ?name then work instead of ".name" as well? Not sure that makes its use more/less/equal consistent with the previous suggestion. Apologies if this has been discussed, I have followed the thread(s) but I might well have forgotten or missed something!

On Tue, Jul 7, 2020 at 8:37 AM Rhodri James wrote:

I'm not quite convinced about making "_" non-binding, mostly because of the knock-on effects in the PEP for other types of patterns. It seems to breed more special cases, and I can't help but feel that's a bad sign.

After spending some time with it in my head and in the actual testbed, it seems like a reasonable compromise. case Point(x,x): being illegal while x,x=(1,2) is perfectly legal is a bit of contention, but grammar also doesn't need to be perfectly consistent in order to learn to speak a language, it just needs to minimize the context-switching. It'd be so simple if we could use case *:, but alas.

On Tue, 7 Jul 2020 at 17:09, Paul Moore wrote:

On Tue, 7 Jul 2020 at 15:40, Henk-Jaap Wagenaar wrote:

...

On Tue, 7 Jul 2020 at 15:04, Rob Cliffe via Python-Dev <

python-dev@python.org> wrote:

...

...

I don't like the .name syntax (grit on Tim's monitor; does not suggest the meaning). [...] But I don't know what syntax (where

necessary) to suggest.

+1(000)

There's been traffic on the PEP repository which suggests that there is a new version of the PEP incoming which responds to these types of concern. I'm not willing to read raw rst diffs, so I haven't checked any of the details.

"PEP 622: Ditch leading dots for name loads": this is now an ex-syntax, it is bereft of life (for this, draft, of the PEP, might come back later!): https://github.com/python/peps/commit/f1de4f169d762cbb46fbfe94d2c01839db9b2f... In there, it makes a good point that namespaced constants are good, especially for this kind of thing (you probably want to e.g. match over a bunch of possible constants which you can then put in an enum or some other namespace).

On 8/07/20 5:30 am, Paul Sokolovsky wrote:

from __future__ import const

FOO: const = 1

match val: case FOO: # obviously matches by constant's value

This would make it *more* difficult to distinguish constants from assignment targets when looking at the match statement, unless you choose names which "look constant-like" somehow. It also has the general problem of const-declarations in Python. Currently the compiler only has to analyse one module at a time; this would require it to also look inside imported modules to determine whether things were declared const. -- Greg

Hello, On Wed, 08 Jul 2020 12:45:09 +1200 Greg Ewing wrote:

On 8/07/20 5:30 am, Paul Sokolovsky wrote:

...

from __future__ import const

FOO: const = 1

match val: case FOO: # obviously matches by constant's value

This would make it *more* difficult to distinguish constants from assignment targets when looking at the match statement, unless you choose names which "look constant-like" somehow.

Sure, the talk was about good technical means to distinguish symbolic constants and variables for pattern matching. These technical means alone are no replacement for stylistic conventions which improve readability of the code. In this regard, it's no different than e.g. conventions of naming classes vs variables.

It also has the general problem of const-declarations in Python. Currently the compiler only has to analyse one module at a time; this would require it to also look inside imported modules to determine whether things were declared const.

Indeed, adding some "const" at the core language level would give many benefits, which certainly would be utilized by (even simple, as embedded in CPython) compilers. E.g. better inter-module scope resolution and optimization, an example of which you give. In terms of complexity, that would be minor comparing to e.g. introducing a parser with unbound memory usage, as done in https://www.python.org/dev/peps/pep-0617 .

-- Greg

-- Best regards, Paul mailto:pmiscml@gmail.com

On Thu, Jul 09, 2020 at 01:22:48AM +1000, Steven D'Aprano wrote:

Whenever someone says "Python is the only language..." it really turns out to be the case. Python is very rarely as unusual as people often make out.

Gah, embarrasing typo! That was meant to be *rarely* turns out to be the case, sorry for any confusion. -- Steven

On Wed, Jul 8, 2020, 12:22 PM Paul Sokolovsky

popular VHLL/scripting languages which doesn't support defining of constants in the core language:

JavaScript has "const foo = 1;" PHP has "const foo = 1;" Perl has "use constant foo => 1;" Lua has "local foo <const> = 1" -----

...

- Mathematica - Scheme - Powershell and other scripting languages like bash - Applescript and Hyperscript - Ruby

I'm pretty sure some on Steven's list are more *popular* than some on Paul's list. What methodology for ranking popularity you use might change details. But none of Steven's are rate, obscure, vanity languages.

On Wed, Jul 8, 2020, 1:00 PM Paul Sokolovsky

Right. So, if someone would like to add something to this thread, I'd humbly suggest to concentrate on the lack of, and need for, of const-ness in the Python language core (in comparison to other languages or not), and usecases it enables, and not on criteria for "popularness".

I admit I do not really understand what gain dynamic languages get from constants. I pretty uniformly use a common convention of ALLCAPS for constant names (knowing they are not really const in Python or bash, where I tend to use them). I think that clarifies intent in an important way. But checking it feels like a job for linters, or perhaps for a future mypy or other type checker. I can easily imagine that a VM might gain speed with that information, but that alone does not feel like enough reason for a language change.

Hello, On Wed, 8 Jul 2020 13:15:19 -0400 David Mertz wrote:

On Wed, Jul 8, 2020, 1:00 PM Paul Sokolovsky

...

Right. So, if someone would like to add something to this thread, I'd humbly suggest to concentrate on the lack of, and need for, of const-ness in the Python language core (in comparison to other languages or not), and usecases it enables, and not on criteria for "popularness".

I admit I do not really understand what gain dynamic languages get from constants. I pretty uniformly use a common convention of ALLCAPS for constant names (knowing they are not really const in Python or bash, where I tend to use them).

Roughly speaking, it's the same "gain" as e.g. (type) annotations. Indeed, const'ness is a kind of simple type annotation.

I think that clarifies intent in an important way.

The talk is about formalizing specification of this intent beyond just stylistic conventions, like case of names. E.g.: def foo(): pass bar = foo # bar is a variable which stores a reference to a function # (can be reassigned with another function) baz: const = foo # baz is an alias for foo()

But checking it feels like a job for linters, or perhaps for a future mypy or other type checker.

I can easily imagine that a VM might gain speed with that information, but that alone does not feel like enough reason for a language change.

If people are satisfied with Python's performance story as presented by CPython, perhaps. Because otherwise, having a formal constants in the code allows for simple and obvious optimizations: instead of looking up value by name at runtime, you can use literal value at the compile time. If anything, lack of const in Python looks like an accidental gap (https://en.wikipedia.org/wiki/Accidental_gap): there're general annotations "with almost arbitrary" syntax, but there's no simple annotation with very obvious and useful semantics. There's support for "dict versions" (PEP 509), so you could catch cases when something was changed behind your back, and no means to say that something just should not change behind your back. There's a "meta-tracing" JIT and a number of failed corporate projects, and no means to develop a simple effective JIT, where user in control of making it more optimal (just mark things const and you don't need all those dict versions and runtimes guards, which take space in your instruction cache and put limit on how fast things can be). Finally, there's pattern matching PEP 622, which initially proposed a funny syntax, and now accidental-gap's matching by non-namespaced constants. All this gives feeling that Python skipped development of a simple and useful notion (const'ness, again), and its lack leads to more skips and unbeautiful workarounds with more complex features in the language. -- Best regards, Paul mailto:pmiscml@gmail.com

On Tue, Jul 7, 2020 at 9:09 AM Paul Moore wrote:

Hopefully the PEP authors intend to post an updated version (preferably with a summary of changes, for people struggling to keep up with the traffic here!) sometime soon.

Please consider that the PEP authors also are struggling with the traffic here. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...

On Tue, 7 Jul 2020 at 15:04, Rob Cliffe via Python-Dev < python-dev@python.org> wrote:

I don't like the .name syntax (grit on Tim's monitor; does not

...

suggest the meaning). [...] But I don't know what syntax (where necessary) to suggest.

https://photos.app.goo.gl/xN68s3QMMBTPTLD47 Look about two character spaces left of "I don't like..." As I read this part of Rob's post this morning, I thought he was surreptitiously making a point about grit on the screen, when I noticed it was *literally grit on the screen*. I cannot convey how long it took me to recover.

On 07/07/2020 16:31, Henk-Jaap Wagenaar wrote:

I used to be in this "camp", however, a (I think valid) point was raised that "else:" is not a (full) alternative. Due to the restriction on repeated names (e.g. Point(x, x) is illegal), if you want to "throw away" intermediate matches, you will have to either have to come up with new names (Point(unused_1, unused_2)) or use the "_" as currently instituted (Point(_, _)) and "else:" does not cover that insofar as I can tell.

Personally I think using _ as throwaway name is perfectly fine, as it is in the rest of Python. The only exception would then be that _ is allowed to be repeated, whereas other identifiers aren't. I'd be ok with that. What I don't like is the use of _ as catch-all, which is different and not interdependent with its use as throwaway. On 08/07/2020 07:26, Steven Barker wrote:

To sum up, I feel like using constructor and keyword-argument syntax to access attributes is an abuse of notation. I'd much prefer a new syntax for matching classes and their attributes that was not so likely to be confusing due to imperfect parallels with class construction. +1

Ideally something like Datetime.year=x would be in my opinion clear at a glance (and reference vs. assignment could be accomplished simply by having == for reference and = for assignment), but it's problematic when it comes to mentioning multiple attributes. A couple ideas: 1. Datetime[year=x, months==3, days==SOME_CONST] 2. (Datetime.year=x, months==3, days==SOME_CONST) 3. Datetime.year=x .months==3 .days==SOME_CONST 4. Datetime.year=x, .months==3, .days==SOME_CONST With no class, this would perhaps favour usage of = and/or == before names to resolve the reference vs. assignment dispute.

On 03/07/2020 21:55, Rob Cliffe wrote:

    I don't like the .name syntax (grit on Tim's monitor; does not suggest the meaning).  Nor am I keen on "expressions" being interpreted differently after 'case' than elsewhere in Python.  But I don't know what syntax (where necessary) to suggest.     I'm not keen on special treatment of the '_' variable, and would prefer to be able to use 'else:' after 'match'.

+1 I think using else would be sensible since it has similar behaviour in the rest of Python and it would immediately make sense to anyone seeing the syntax for the first time (provided they understood what the rest of the match block does). If objections were moved against it I seem to have missed them (in my defence, the discussion on PEP622 has been quite fragmented and I haven't been on this list for very long). I also don't like the .name syntax and for what little it's worth, I personally would have a hard time getting used to it if it were adopted. Has anyone proposed introducing ` ` quotes for this purpose? They could enclose references without ambiguity and could even be used elsewhere in Python to enclose identifiers, for example to allow spaces and symbols in them (which I wouldn't regard as particularly good style, but it may still come in handy). They are used in MySQL, bash and Markdown to enclose expressions or identifiers, so I feel no experienced programmer would have a hard time wrapping their head around it. Though I'd understand if it were problematic for Python's parser. Another option would be to wrap references in {} in a similar way to what happens in fstrings. Another option still could be to wrap references in quotes, like strings, and require use of str("some string") to catch literal strings, but I don't know if I like this myself. Either way, I seem to prefer symmetric marks to signal references; I don't know if anyone else shares this sentiment.

On 8/07/20 12:24 pm, Daniel Moisset wrote:

Many people in this thread have argued that the double meaning in the PEP might be confusing, but Python already has a double meaning in other places.

But assignment targets have always been clearly separated by being on the left of an assignment operator, either = or :=. The PEP proposes to intermingle them, with only very subtle clues, such as the presence or absence of dots, to distinguish them. -- Greg

On 8/07/20 12:48 pm, Chris Angelico wrote:

"for x[0] in iter:" uses x[0] as an assignment target,

You're right, there are some others, but I think they're equally clear -- all the ones I can think of are directly after a keyword ("for", "as", "import", etc.) But in match statements, they can be arbitrarily intermingled with other expression-like stuff.

You're right about the presence/absence of a dot being very subtle, but hang tight, wait for the next publication of the PEP; its authors are working on that exact problem.

It looks like the only thing they're doing is dropping the *leading* dot case -- without providing any replacement for it. That only addresses one small part of my concern, since I think the non-leading dot is nearly as subtle. Maybe even more so, since at least the leading dot was obviously something different. Also I don't like the idea of being *forced* to use a namespace for my constants, regardless of how good an idea the PEP authors think it is. -- Greg

On Wed, 1 Jul 2020 21:14:00 +0100 Rob Cliffe via Python-Dev wrote:

Whoa!

I have an uneasy feeling about this PEP.

AFAIK the usual procedure for adding a new feature to Python is:     An idea is raised and attracts some support.     Someone sufficiently motivated writes a PEP.     The PEP is thoroughly discussed.     Eventually a consensus (or at least an "agree to differ" stalemate) is reached.     The PEP is accepted (if it is).     (Then and only then) Someone works on the implementation.         etc.

However, PEP 622 only seems to have been presented to the Python community only *after* a well-developed (if not finalised) implementation was built.  A fait accompli.

I think what you describe as "the usual procedure" isn't as usual as you think. For example, when I wrote PEP 442 (Safe object finalization), I don't remember a preliminary round of raising support for the idea. I had that idea in mind after repeated frustration with the previous finalization semantics, attempted writing an implementation which ended up functional, and then wrote a PEP from it. That said, PEP 622 is a much broader PEP adding a whole new syntactical feature with unusual semantics attached to it, so it's conceivable to be more cautious with the discussion process. Regards Antoine.

On Fri, Jul 3, 2020, 12:40 Eric Snow wrote:

Also, keep in mind that PEPs are a tool for the decision maker (i.e. BDFL delegate). Effectively, everything else is convention. The process usually involves community feedback, but has never been community-driven. All this has become more painful for volunteers as the Python community has grown.

-eric

To further elaborate on that, a PEP isn't legislation to be approved by the community. Rather, it is meant to capture the proposal and discussion sufficiently that the BDFL/delegate can make a good decision. Ultimately there isn't much more to the process than that, beyond convention. The BDFL-delegate is trusted to do the right thing and the steering council is there as a backstop. It's up to the decision maker to reach a conclusion and it makes sense that they especially consider community impact. However, there is no requirement of community approval. This is not new. Over the years quite a few decisions by Guido (as BDFL) sparked controversy yet in hindsight Python is better for each of those decisions. (See PEP 20.) The main difference in recent years is the growth of the Python community, which is a happy problem even if a complex one. :) There has been a huge influx of folks without context on Python's governance but with contrary expectations and loud voices. On the downside, growth has greatly increased communications traffic and signal-to-noise, as well as somewhat shifting tone in the wrong direction. Unfortunately all this contributed to us losing our BDFL. :( Thankfully we have the steering council as a replacement. Regardless, Python is not run as a democracy nor by a representative body. Instead, this is a group of trusted volunteers that are trying their best to keep Python going and make it better. The sacrifices they make reflect how much they care about the language and the community, especially as dissenting voices increase in volume and vitriol. That negativity has a real impact. -eric

On Fri, Jul 3, 2020 at 7:39 AM Rob Cliffe via Python-Dev < python-dev@python.org> wrote:

Whoa!

I have an uneasy feeling about this PEP.

AFAIK the usual procedure for adding a new feature to Python is: An idea is raised and attracts some support. Someone sufficiently motivated writes a PEP. The PEP is thoroughly discussed. Eventually a consensus (or at least an "agree to differ" stalemate) is reached. The PEP is accepted (if it is). (Then and only then) Someone works on the implementation.

That "then and only then" part is not correct. It just happens to be typical due to people wanting to see if their idea has any support before putting in the effort to actually code it up. Personally I sometimes wonder if we should require a proof-of-concept upfront for all PEPs that introduce a code change.

etc.

However, PEP 622 only seems to have been presented to the Python community only *after* a well-developed (if not finalised) implementation was built. A fait accompli. So there will inevitably be resistance from the developers to accept changes suggested on python-dev.

Then that's on them. But it may backfire if people don't like what there PEP is presenting.

And since the PEP has Guido's authority behind it, I think it is likely that it will eventually be accepted pretty much as it was originally written.

I'm trying to not take that as an insult, but I will say the steering council does not rubber stamp Guido's PEPs. We do debate them and consider them like any other PEP. It's not our fault he has a good sense of design even in retirement. 😉 So as usual, once this PEP is ready for consideration (which it isn't as stated by the PEP authors), we will consider it like any other PEP that tries to change the language.

This means that most of the discussion we have seen on python-dev (and there has been a lot) will end up being just pissing in the wind.

Once again, it is at the PEP author's peril to not listen to people's suggestions and risk the PEP not being accepted due to the design not meeting standards for acceptance. And they are still required to keep the Rejected Ideas section of the PEP up-to-date or else the PEP will not be considered.

(I don't mean to be vulgar or disrespectful; I just can't think of another phrase that conveys my meaning so well.)

I think you're looking for "ignored". -Brett

And Guido's 2nd email ("PEP 622: Structural Pattern Matching -- followup") already to me (YMMV) reads rather like "OK, you've had your fun, now try not to joggle our elbows too much while we get on with the work".

I don't know how many of the decisions made in the PEP are right and how many could be improved (it is of course a subjective question anyway). I do think it's a pity that the Python community did not have the chance to supply feedback earlier down the road (when IMO it would have been taken more seriously). While Guido and the other developers have obviously already put a huge amount of work into this PEP (and by now probably have a significant emotional investment in it), I do hope that they will take the time to consider seriously and on their merits most/all suggested changes, rather than being tempted to rush through the acceptance and implementation of the PEP.

Best wishes Rob Cliffe _______________________________________________ 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/IG4VNKZF... Code of Conduct: http://python.org/psf/codeofconduct/

Since I took it upon myself to implement PEP 622, I just have a few thoughts to add to the other excellent responses here. Hopefully these will help clarify that the intent is not to "railroad" anything. Rob Cliffe wrote:

PEP 622 only seems to have been presented to the Python community only after a well-developed (if not finalised) implementation was built.

Well, thanks for the "well-developed" bit, but I promise that the implementation is far from final. Since we first published the PEP, I've made dozens of commits touching pretty much every new line of code several times. Just last week we gutted the __match__ method in response to well-reasoned calls to defer it.

So there will inevitably be resistance from the developers to accept changes suggested on python-dev.

As the one who has been doing almost all of the development, I assure you this isn't true. 80% of the PEP's authors have been almost entirely detached from development of the reference implementation, so I would be very surprised if they gave my existing work more weight than the opinions of the community... I wrote the thing, and I certainly don't! I volunteered to implement it because I thought the PEP and implementation would be an interesting project while trapped at home this spring. I *like* doing this stuff, so I'm not really worried about getting to do more of it. ;)

And since the PEP has Guido's authority behind it, I think it is likely that it will eventually be accepted pretty much as it was originally written.

It has already changed quite substantially from how it was originally written. Here's everything that's changed since we posted the first draft (we've been pretty much dominating PEP repo traffic over the past week): https://github.com/python/peps/commits/master/pep-0622.rst Again, you'll notice that the entire __match__ protocol was deferred based on feedback we received, and we've made an effort to describe the reasoning behind many decisions that seemed obvious to us but weren't to others. The opening sections are also getting a rewrite (again, based on Python-Dev feedback).

Guido's 2nd email ("PEP 622: Structural Pattern Matching -- followup") already to me (YMMV) reads rather like "OK, you've had your fun, now try not to joggle our elbows too much while we get on with the work".

That's an extremely odd way to interpret his thread, which exists solely to collect of all of the "unheard" critiques in one central location.

I do think it's a pity that the Python community did not have the chance to supply feedback earlier down the road (when IMO it would have been taken more seriously).

It did. The very first thing we did was perform detailed surveys of 8 different Python-Ideas threads (spanning 9 years), 13 other languages, and a handful of the most popular Python packages for pattern matching. This is not at all the first time this has been brought up by the community; I personally worked my way through hundreds of emails and dozens of documents before writing a single line of code (or PEP).

While Guido and the other developers have obviously already put a huge amount of work into this PEP (and by now probably have a significant emotional investment in it), I do hope that they will take the time to consider seriously and on their merits most/all suggested changes, rather than being tempted to rush through the acceptance and implementation of the PEP.

Don't worry; I have a much stronger emotional connection to Python's continued success and community than to a quarantine project that Guido nerd-sniped me with a few months ago. ;) Brandt

On Wed, Jul 8, 2020 at 7:03 AM Kerwin Sun wrote:

I tried with this code:

[...]

def whereis(point): case w: print("Not the answer, local w") case z: print("The answer") case _: print("other") whereis(42)

w, z and _ are all equivalent here, therefore it will take the first matching branch. The very first post about 622 contained a caveat that case _: will never be reached if case identifier: exists instead. Equivalent branches are only ignored, not illegal.

It works for me. Did you click on the box where the logs are supposed to appear? It will only show the logs when you click there. On Wed, Jul 8, 2020 at 1:36 PM Henk-Jaap Wagenaar < wagenaarhenkjaap@gmail.com> wrote:

On Wed, 1 Jul 2020 at 17:09, Guido van Rossum wrote:

...

If you are interested in learning more about how PEP 622 would work in practice, but don't feel like compiling a Python 3.10 fork from source, here's good news for you.

In a hurry? https://mybinder.org/v2/gh/gvanrossum/patma/master?urlpath=lab/tree/playgrou...

I could not get this to work yesterday and today. It will eventually say:

"Your session is taking longer than usual to start! Check the log messages below to see what is happening."

But the logs are empty. Is that just me or anybody else too?

I tried Chrome (Windows 10 & macOS) and Safari (macOS).

...

This will open a Binder instance that runs a Jupyter kernel built from Brandt Bucher's fork of Python 3.10 that includes the match statement. This is a complete implementation of the PEP. (Note that we've already made some design changes in response to feedback, but the basic syntax is still the same. Expect a new draft within a week.)

The code for the playground was contributed by Fernando Perez, Matthias Bussonnier and Chris Holdgraf. We also thank the Binder and Jupyter teams for Binder and Jupyter and all the infrastructure that made this playground possible, and we thank gesis.org for hosting.

For details, see https://github.com/gvanrossum/patma/tree/master/binder

-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c... _______________________________________________ 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/47YR2LUT... 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/4IUCFYIU... 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-c...