[Python-Dev] Re: PEP 622: Structural Pattern Matching

On Thu, Jun 25, 2020 at 8:31 PM Richard Damon wrote: > > I thought _ was also commonly used as: > > first, -, last = (1, 2, 3) > > as a generic don't care about assignment. I guess since the above will > create a local, so not overwrite a 'global' function _ for translations, > so the above

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

Thank you very much for putting this PEP together. It would be very helpful to broaden the objective of avoiding functions returning PyObject** to other types of pointers. I have in mind several functions in the C-API that return a char* pointer to the contents of an object. While these

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 6/25/20 6:48 PM, Emily Bowman wrote: > On Thu, Jun 25, 2020 at 3:41 PM Richard Damon > mailto:rich...@damon-family.org>> wrote: > > Actually, you could make _ less special by still binding the value to > > it, just make it special in that you allow several values to be bound, > and

[Python-Dev] Re: PEP 622: Structural Pattern Matching

Litmus test: Give someone who does not know Python this code example from the PEP and ask them what it does and why it does what it does: match get_shape(): case Line(start := Point(x, y), end) if start == end: print(f"Zero length line at {x}, {y}") I expect confusion to be the

[Python-Dev] Re: Intended invariants for signals in CPython

What, weird edge cases involving *signals?* Never! :) Here's a nice simple one: it takes at least a few opcodes to set said global flag, during which (depending on the whims of how eval_break gets set) yet another signal might get raised and handled. I did just make a post to python-ideas about

[Python-Dev] Re: The Anti-PEP

On Thu, Jun 25, 2020 at 6:49 PM Raymond Hettinger < raymond.hettin...@gmail.com> wrote: > > it is hard to make a decision between the pros and cons, > > when the pros are in a single formal document and the > > cons are scattered across the internet. > > Mark, I support your idea. It is natural

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On Wed, Jun 24, 2020 at 7:58 PM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Ethan Furman writes: > > > _ does not bind to anything, but of what practical importance is that? > > *sigh* English speakers ... mutter ... mutter ... *long sigh* > > It's absolutely essential to

[Python-Dev] Re: Intended invariants for signals in CPython

HOLY CRAP THIS IS MADNESS. I kind of love it. :) And it's related to some other problems that have been on my mind (how to "paint" stack frames with user-defined variables, with those variables then being used by things like CPU/heap profilers as smart annotations), and I have to say it's a

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On Wed, Jun 24, 2020 at 7:34 PM Taine Zhao wrote: > > e.g., "or", and then I wonder "what does short-circuiting have to do > > with it?". All reuse of symbols carries baggage. > > "or" brings an intuition of the execution order of pattern matching, just > like how people already know about

[Python-Dev] Re: The Anti-PEP

> it is hard to make a decision between the pros and cons, > when the pros are in a single formal document and the > cons are scattered across the internet. Mark, I support your idea. It is natural for PEP authors to not fully articulate the voices of opposition or counter-proposals. The

[Python-Dev] Re: Intended invariants for signals in CPython

I had not -- thank you! On Thu, Jun 25, 2020 at 1:49 PM Chris Jerdonek wrote: > On Wed, Jun 24, 2020 at 5:15 PM Yonatan Zunger via Python-Dev < > python-dev@python.org> wrote: > >> That said, the meta-question still applies: Are there things which are >> generally intended *not* to be

[Python-Dev] Re: The Anti-PEP

Brett Cannon writes: > I agree, and that's what the Rejected Ideas section is supposed to > capture. Perhaps there could be guidance, in documentation (and if appropriate from the PEP-Delegate or the Steering Council), that the PEP proponent collaborate with a leading opponent, critic, and/or

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On Thu, 25 Jun 2020, Richard Damon wrote: On 6/25/20 10:42 AM, Greg Ewing wrote: On 26/06/20 1:18 am, Rhodri James wrote: I will quickly and regularly forget that in this one place, "_" is special. You don't have to remember that it's special to understand what 'case _' does. Even if it

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 26/06/20 5:07 am, MRAB wrote: How do you indicate that you want it to match anything and don't care about the value? case Spam(-> _): Or if that's considered too verbose and we're willing to make _ even more special, it could be just case Spam(_): In that case we would be regarding

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

Ethan Furman wrote: > Ouch. That seems like a pretty serious drawback. Will this issue be > resolved? It's currently being revisited. Realistically, I'd imagine that we either find some straightforward way of opting-in to the current default behavior (allowing one arg to be positionally

[Python-Dev] Re: PEP 622: Structural Pattern Matching

In this example code from the PEP: match shape: case Point(x, y): ... case Rectangle(x0, y0, x1, y1, painted=True): What is the "painted=True" portion doing? Is it requiring that the painted attribute of the shape object be True in order to match? -- ~Ethan~

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

On 06/25/2020 04:07 PM, Brandt Bucher wrote: Pablo Galindo Salgado wrote: ...users can do a positional match against the proxy with a name pattern: match input: case datetime.date(dt): print(f"The date {dt.isoformat()}" ...if 'datetime.date' were updated to implement a

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

Pablo Galindo Salgado wrote: > ...users can do a positional match against the proxy with a name pattern: > > match input: > case datetime.date(dt): > print(f"The date {dt.isoformat()}" > > ...if 'datetime.date' were updated to implement a non-default __match_args__, > allowing

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On Thu, Jun 25, 2020 at 3:41 PM Richard Damon wrote: > Actually, you could make _ less special by still binding the value to > it, just make it special in that you allow several values to be bound, > and maybe just define that the result will be just one of the values, > maybe even specify which

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

On Wed, Jun 24, 2020 at 12:46 PM Guido van Rossum wrote: > Everyone, > > If you've commented and you're worried you haven't been heard, please add > your issue *concisely* to this new thread. Note that the following issues > are already open and will be responded to separately; please don't

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 6/25/20 10:42 AM, Greg Ewing wrote: > On 26/06/20 1:18 am, Rhodri James wrote: >> I will quickly and regularly forget that in this one place, "_" is >> special. > > You don't have to remember that it's special to understand what > 'case _' does. Even if it were treated as an ordinary name, it >

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On Thu, Jun 25, 2020 at 9:21 AM Rhodri James wrote: > Well, now is the time for expressing surprise :-p > > As I've said before, one of my main problems with the PEP is as you go > through it, more and more special cases and surprises appear, and the > consequences of earlier surprises generate

[Python-Dev] Re: Intended invariants for signals in CPython

On Wed, Jun 24, 2020 at 5:15 PM Yonatan Zunger via Python-Dev < python-dev@python.org> wrote: > That said, the meta-question still applies: Are there things which are > generally intended *not* to be interruptible by signals, and if so, is > there some consistent way of indicating this? >

[Python-Dev] Re: The Anti-PEP

On Thu, Jun 25, 2020 at 11:52 AM Brett Cannon wrote: > On Thu, Jun 25, 2020 at 5:45 AM Antoine Pitrou > wrote: > >> I don't think this really works. A PEP has to present a consistent >> view of the world, and works as a cohesive whole. Arguments against a >> PEP don't form a PEP in

[Python-Dev] Re: Intended invariants for signals in CPython

On Thu, 25 Jun 2020 11:18:13 -0700 Yonatan Zunger via Python-Dev wrote: > Also, just to sanity-check that I understand things correctly: Python > signal handlers *are* reentrant, in that a signal handler can be > interrupted by another signal, is that right? Is there any general > recommendation

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On Thu, Jun 25, 2020 at 3:17 AM Greg Ewing wrote: > On 25/06/20 7:50 pm, Anders Munch wrote: > > Pascal is a precedent for this placement of 'case', > > Yes, but it doesn't use it with "match". In fact it doesn't have > any keyword in front of the values to be matched; it goes like > > case

[Python-Dev] Re: The Anti-PEP

On Thu, Jun 25, 2020 at 5:45 AM Antoine Pitrou wrote: > On Thu, 25 Jun 2020 11:57:49 +0100 > Mark Shannon wrote: > > > > An Anti-PEP is a way to ensure that those opposed to a PEP can be heard > > and, if possible, have a coherent voice. > > Hopefully, it would also make things a lot less

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 06/25/2020 03:00 AM, Greg Ewing wrote: On 25/06/20 7:50 pm, Anders Munch wrote: Pascal is a precedent for this placement of 'case', Yes, but it doesn't use it with "match". In fact it doesn't have any keyword in front of the values to be matched; it goes like    case n of   1:

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

I was talking with a colleague today about the PEP and he raised a couple of question regarding the match protocol and the proxy result. One question is that taking into account that 'case object(x)' is valid for every object, but it does (could do) something different for objects that have a

[Python-Dev] Re: Intended invariants for signals in CPython

Also, just to sanity-check that I understand things correctly: Python signal handlers *are* reentrant, in that a signal handler can be interrupted by another signal, is that right? Is there any general recommendation on how to write signal handlers in order to manage that? (Antoine, I *so* wish I

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On Wed, Jun 24, 2020 at 1:38 PM Luciano Ramalho wrote: > Thank you Guido, Brandt Bucher, Tobias Kohn, Ivan Levkivskyi and Talin > for this fun and very useful new feature. > > I do enjoy pattern matching a lot in Elixir—my favorite language these > days, after Python. > > I don't want to start a

[Python-Dev] Re: Intended invariants for signals in CPython

I'm taking it from this thread that suppressing signals in a small window is not something anyone in their right mind would really want to attempt. :) (Or that if they did, it would have to be through a proper change to the runtime, not something higher-level) On Thu, Jun 25, 2020 at 7:14 AM

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 2020-06-25 08:50, Anders Munch wrote: Eric Nieuwland : I have some doubt about the keyword Guido van Rossum [mailto:gu...@python.org]: Many people have tried to come up with a different keyword here, but nothing has been found that comes even close to the simplicity of match. Plus, several

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 2020-06-25 04:54, Greg Ewing wrote: I had another thought about a way to make the bound names explicit. # Keyword case Point(x -> px, y -> py): # Positional case Point(-> x, -> y): # Sub-pattern, positional case Line(Point() -> p1, Point() -> p2): #

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 25/06/2020 16:48, Tim Peters wrote: [Tim] See reply to Glenn. Can you give an example of a dotted name that is not a constant value pattern? An example of a non-dotted name that is? If you can't do either (and I cannot)), then that's simply what "if [Rhodri James ] case

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Tim] See reply to Glenn. Can you give an example of a dotted name that is not a constant value pattern? An example of a non-dotted name that is? If you can't do either (and I cannot)), then that's simply what "if [Rhodri James ] >>> case long.chain.of.attributes: [Tim] >>

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 25/06/2020 15:42, Greg Ewing wrote: On 26/06/20 1:18 am, Rhodri James wrote: I will quickly and regularly forget that in this one place, "_" is special. You don't have to remember that it's special to understand what 'case _' does. Even if it were treated as an ordinary name, it would

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 25/06/2020 15:40, Tim Peters wrote: [Rhodri James ] See reply to Glenn. Can you give an example of a dotted name that is not a constant value pattern? An example of a non-dotted name that is? If you can't do either (and I cannot)), then that's simply what "if case

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

> '?foo' or 'foo?' to mark a variable binding I like that idea a lot, with a strong inclination for the '?foo' variant. Seeing the '?' first makes it clear right away that it's a special context. And it keeps it more distinct from the None-aware operators (from PEP 505, in case that gets

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On Thu, 25 Jun 2020, 16:48 Eric Nieuwland, wrote: > And maybe also an additional operator: > > if X matches Y: > Z > This is really different from the PEP, but I like it, it reminds me of the if let matching in Rust. ___ Python-Dev mailing list --

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 26/06/20 1:18 am, Rhodri James wrote: I will quickly and regularly forget that in this one place, "_" is special. You don't have to remember that it's special to understand what 'case _' does. Even if it were treated as an ordinary name, it would still have the effect of matching anything.

[Python-Dev] Re: PEP 622: Structural Pattern Matching

Guido van Rossum wrote: > Eric Nieuwland wrote: > >> I have some doubt about the keyword: ‘match' seems to be at odds with >> 'for', 'while', 'with', 'if' as it is more of an action. >> It's more like 'try' but that statement has a completely different >> structure. > > Well, 'try' is also an

[Python-Dev] Re: PEP 622: Structural Pattern Matching

[Rhodri James ] > I'm seriously going to maintain that I will forget the meaning of "case > _:" quickly and regularly, Actually, you won't - trust me ;-) > just as I quickly and regularly forget to use > "|" instead of "+" for set union. More accurately, I will quickly and > regularly forget

[Python-Dev] Re: The Anti-PEP

In my experience, different people keep proposing the same idea until it's recorded in the PEP. The PEP doesn't have to address all remarks or take in account all ideas, but it's good to record the most common proposed ideas. The important part is to show that other people's opinions have been

[Python-Dev] Re: Intended invariants for signals in CPython

Le 25/06/2020 à 16:00, Guido van Rossum a écrit : > On Thu, Jun 25, 2020 at 02:02 Antoine Pitrou > wrote: > > ...  The intent, though, is that any function > waiting on an external event (this can be a timer, a socket, a > lock, a directory...) should be

[Python-Dev] Re: Intended invariants for signals in CPython

On Thu, Jun 25, 2020 at 02:02 Antoine Pitrou wrote: > ... The intent, though, is that any function > waiting on an external event (this can be a timer, a socket, a > lock, a directory...) should be interruptible so that Ctrl-C works in > an interactive prompt. > That’s not really true though

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 2020-06-25 03:00, Greg Ewing wrote: On 25/06/20 7:50 pm, Anders Munch wrote: Pascal is a precedent for this placement of 'case', Yes, but it doesn't use it with "match". In fact it doesn't have any keyword in front of the values to be matched; it goes like    case n of   1: ...;  

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 25/06/2020 00:54, Tim Peters wrote: [Ethan Furman ] "case _:" is easy to miss -- I missed it several times reading through the PEP. As I said, I don't care about "shallow first impressions". I care about how a thing hangs together _after_ climbing its learning curve - which in this case

[Python-Dev] Re: The Anti-PEP

On 25.06.2020 13:57, Mark Shannon wrote: Hi, I'd like to propose the "Anti-PEP". As I'm sure you've all noticed, contentious PEPs like 572, and now 622, generate a lot of email discussion. It's easy to feel that people's opinions are being dismissed and that legitimate criticisms aren't

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

On 25/06/2020 10:15, Chris Angelico wrote: On Thu, Jun 25, 2020 at 6:53 PM Antoine Pitrou wrote: On Wed, 24 Jun 2020 12:38:52 -0700 Guido van Rossum wrote: Everyone, If you've commented and you're worried you haven't been heard, please add your issue *concisely* to this new thread. Note

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

Without arguing for or against allowing a capture variable, IMO rather than syntax like     match into : it would be far better (and not require a new keyword) to write this as     with as match : Rob Cliffe PS:  Or     = match On 24/06/2020 20:38, Guido van Rossum wrote: Everyone, If

[Python-Dev] Re: The Anti-PEP

On Thu, 25 Jun 2020 11:57:49 +0100 Mark Shannon wrote: > > An Anti-PEP is a way to ensure that those opposed to a PEP can be heard > and, if possible, have a coherent voice. > Hopefully, it would also make things a lot less stressful for PEP authors. I don't think this really works. A PEP has

[Python-Dev] Re: The Anti-PEP

A natural question that arises is who will be responsible for authoring it? I'd guess anyone with a strong enough opinion (and there's no shortage of those) could be the one who does it. Separating bikeshedding from refusals/rejections definitely has merit though, especially for the person making

[Python-Dev] The Anti-PEP

Hi, I'd like to propose the "Anti-PEP". As I'm sure you've all noticed, contentious PEPs like 572, and now 622, generate a lot of email discussion. It's easy to feel that people's opinions are being dismissed and that legitimate criticisms aren't being heard. Conversely, PEP authors may feel

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 6/25/2020 3:55 AM, Kyle Stanley wrote: > 2) Regarding the constant value pattern semantics, I'm okay with the > usage of the "." in general, but I completely agree with several > others that it's rather difficult to read when there's a leading > period with a single word, e.g. ".CONSTANT". To

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 25/06/20 7:50 pm, Anders Munch wrote: Pascal is a precedent for this placement of 'case', Yes, but it doesn't use it with "match". In fact it doesn't have any keyword in front of the values to be matched; it goes like case n of 1: ...; 2: ...; 3: ...; end If we did

[Python-Dev] Re: PEP 622: Structural Pattern Matching

After reading a GitHub discussion on the matter (https://github.com/gvanrossum/patma/issues/93), '|' now makes sense to me instead of 'or': - The use of the '|' character in Python seems to be going towards a union-like operator (dict merging, PEP 604), which is definitely appropriate here. -

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

On Thu, Jun 25, 2020 at 6:53 PM Antoine Pitrou wrote: > > On Wed, 24 Jun 2020 12:38:52 -0700 > Guido van Rossum wrote: > > Everyone, > > > > If you've commented and you're worried you haven't been heard, please add > > your issue *concisely* to this new thread. Note that the following issues > >

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

Le mer. 24 juin 2020 à 21:16, Stefan Behnel a écrit : > It couldn't because even today it is still fairly difficult to convert > existing code to the limited API. Some code cannot even be migrated at all, > e.g. because the entire buffer protocol is missing from it. Some bugs were > only fixed in

[Python-Dev] Re: Intended invariants for signals in CPython

On Wed, 24 Jun 2020 16:54:34 -0700 Yonatan Zunger via Python-Dev wrote: > ... Reading through more of the code, I realized that I greatly > underestimated the number of interruptible operations. > > That said, the meta-question still applies: Are there things which are > generally intended *not*

[Python-Dev] Re: PEP 622: Structural Pattern Matching -- followup

On Wed, 24 Jun 2020 12:38:52 -0700 Guido van Rossum wrote: > Everyone, > > If you've commented and you're worried you haven't been heard, please add > your issue *concisely* to this new thread. Note that the following issues > are already open and will be responded to separately; please don't

[Python-Dev] Re: PEP 622: Structural Pattern Matching

Thank you very much to Brandt, Tobias, Ivan, Guido, and Talin for the extensive work on this PEP. The attention to detail and effort that went into establishing the real-world usefulness of this feature (such as the many excellent examples and code analysis) helps a lot to justify the complexity

[Python-Dev] Re: PEP 622: Structural Pattern Matching

Eric Nieuwland : >> I have some doubt about the keyword Guido van Rossum [mailto:gu...@python.org]: > Many people have tried to come up with a different keyword here, but nothing > has been found that comes even close to the simplicity of match. Plus, several > other languages (Scala, Rust) use it

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 25/06/20 4:24 pm, Emily Bowman wrote: There's always making everyone equally annoyed, and allowing 'case else:' Visual Basic does actually use "case else". (And "select case" at the beginning, just to be as annoying as possible.) -- Greg ___

[Python-Dev] Re: PEP 622: Structural Pattern Matching

On 25/06/20 8:49 am, Tim Peters wrote: Spell it, e.g., "or", and then I wonder "what does short-circuiting have to do with it?". Well, it does short-circuit -- if one alternative matches, it doesn't bother with any subsequent ones. Which could be considered an argument for using "or" instead