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

On 25/06/20 6:36 am, Brandt Bucher wrote: Another option I've considered is using the `keys` method, since most non-dict mappings would get this called anyways for patterns with `**rest`. All the more reason why we should allow the implementation some flexibility. ;) My concern was only that

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

On Wed, Jun 24, 2020 at 3:15 PM Ethan Furman wrote: > > I too thought "why not else:?" at first. But "case _:" covers it in > > the one obvious way after grasping how general wildcard matches are. > > "case _:" is easy to miss -- I missed it several times reading through the > PEP. > > >

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

On 25/06/20 3:31 am, Taine Zhao wrote: https://thautwarm.github.io/Site-32/Design/PEP622-1.html In your AND pattern example, you seem to envisage there being a Urlopen class whose __match__ method has the side effect of opening the URL. This makes it much more than just a pattern to be

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

On Jun 23, 2020, at 16:26, Guido van Rossum wrote: > > (I'm replying to several messages in one reply. But there is too much to > respond to so this is merely the first batch.) I’m really glad to know that the PEP 622 team is deliberating internally about all the suggestions and comments made

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

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): # Sub-pattern, keyword case Line(start: Point() -> p1,

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

I don't mean to be rude, but I would like to chip in and back up Taine here. The 'or' operator: - Already unambiguously associated with a logical OR, which is effectively what takes place in this circumstance. Using a different symbol to have the same effect is bound to be confusing to a

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

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 the use of the identifier "_", otherwise the I18N community would riot in the streets of Pittsburgh. Not

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

On Jun 23, 2020, at 23:25, Emily Bowman wrote: > I wonder if it's time to officially designate _ as a reserved name. That would break the i18n use case. Cheers, -Barry signature.asc Description: Message signed with OpenPGP ___ Python-Dev mailing

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

[Taine Zhao ] > "or" brings an intuition of the execution order of pattern matching, just > like how people already know about "short-circuiting". > > "or" 's operator precedence also suggests the syntax of OR patterns. > > As we have "|" as an existing operator, it seems that there might be >

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

> 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 "short-circuiting". "or" 's operator precedence also suggests

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

On 2020-06-24 23:14, Ethan Furman wrote: On 06/24/2020 01:49 PM, Tim Peters wrote: I too thought "why not else:?" at first. But "case _:" covers it in the one obvious way after grasping how general wildcard matches are. "case _:" is easy to miss -- I missed it several times reading through

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

On Wed, Jun 24, 2020 at 5:30 PM Greg Ewing wrote: > On 24/06/20 11:26 am, Guido van Rossum wrote: > > A design pattern where a group of record-like classes is > > combined into a union is popular in other languages that support pattern > > matching and is known under a name of algebraic data

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

On 24/06/20 11:26 am, Guido van Rossum wrote: A design pattern where a group of record-like classes is combined into a union is popular in other languages that support pattern matching and is known under a name of algebraic data types [2]_ or ADTs. Whoo, that's confusing! I read "ADT" as

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

... 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* to be interruptible by signals, and if so, is there some consistent way of

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

[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 is about a nanometer tall ;-) You're

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

[Tim] >> ".NAME" grated at first, but extends the idea that dotted names are >> always constant value patterns to "if and only if". So it has mnemonic >> value. When context alone can't distinguish whether a name is meant as >> (in effect) an lvalue or an rvalue, no syntax decorations can prevent

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

On Tue, Jun 23, 2020 at 5:08 PM Guido van Rossum wrote: > [SNIP] > On Tue, Jun 23, 2020 at 12:11 PM Brett Cannon wrote: > >> I will say that trying to follow >> https://github.com/python/peps/blob/master/pep-0622.rst#runtime-specification >> was really hard. Any chance of getting some

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

On 6/24/2020 1:49 PM, Tim Peters wrote: ".NAME" grated at first, but extends the idea that dotted names are always constant value patterns to "if and only if". So it has mnemonic value. When context alone can't distinguish whether a name is meant as (in effect) an lvalue or an rvalue, no syntax

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

On 06/24/2020 01:49 PM, Tim Peters wrote: I too thought "why not else:?" at first. But "case _:" covers it in the one obvious way after grasping how general wildcard matches are. "case _:" is easy to miss -- I missed it several times reading through the PEP. Introducing "else:" too would be

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

On Wed, 24 Jun 2020 at 16:40, 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 bother

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

> match get_node() into c: +1 to scoping name pattern related objects upfront. (mirrors my post, so no bias :P) Using a namespace to group capture variables is a good idea, though new attributes are introduced throughout the match block. In my view, this is very similar to the use a special

[Python-Dev] Intended invariants for signals in CPython

Hi everyone, I'm in the process of writing some code to defer signals during critical regions, which has involved a good deal of reading through the CPython implementation to understand the behaviors. Something I've found is that there appears to be a lot of thoughtfulness about where the signal

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

I gave a longer example, but the short version is that I cannot tell from the Class Pattern or Runtime section how class patterns interact with properties (i.e. when access changes state). On Wed, Jun 24, 2020, 3:45 PM Guido van Rossum wrote: > Everyone, > > If you've commented and you're

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

I'm also not a big fan of the 'else' proposal. Context matters and in the context of match expressions a case with a wildcard pattern makes sense, an else, not so much. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to

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

You got everything right the first time ;-) The PEP is an extended illustration of "although that way may not be obvious at first unless you're Dutch". I too thought "why not else:?" at first. But "case _:" covers it in the one obvious way after grasping how general wildcard matches are.

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

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 discussion, but I just want to say that as an instructor I fear this

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

On 06/24/2020 11:08 AM, Guido van Rossum wrote: Nearly every other language whose pattern matching syntax we've examined uses _ as the wildcard. The authors don't feel very strongly about whether to use `else:` or `case _:`. The latter would be possible even if we added an explicit `else`

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

El mar., 23 jun. 2020 a las 9:10, Guido van Rossum () escribió: > I'm happy to present a new PEP for the python-dev community to review. > This is joint work with Brandt Bucher, Tobias Kohn, Ivan Levkivskyi and > Talin. > > Thanks to Guido and all the others working on this! It's going to be a

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

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 bother commenting on these until we've done so: - Alternative spellings

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

On Wed, Jun 24, 2020 at 11:47 AM M.-A. Lemburg wrote: > Something I know the Perl camp is always very fond of is the > matching on regexps. Is this possible using the proposal (sorry, > I don't quite understand the __match__() protocol yet) ? > No, that's left for another day. Scala has string

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

On Wed, 24 Jun 2020 at 19:49, M.-A. Lemburg wrote: > match something: > case 0 | 1 | 2 | _: > print("Small number or something else") > case [] | [_]: > print("A short sequence") > case _: > print("Not sure what this is") > case str() | bytes(): >

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

Gustavo Carneiro schrieb am 24.06.20 um 19:19: > On Wed, 24 Jun 2020 at 17:22, Victor Stinner wrote: >> The question becomes: how to promote the limited C API? Should it >> become the default, rather than an opt-in option? > > It would be interesting to find out what is the performance impact of

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

Victor Stinner schrieb am 24.06.20 um 17:40: > My practical problem is how to prevent C extensions accessing the > PyFloatObject.ob_fval member directly. Do extensions really do that in their code? I mean, there *is* a macro for doing exactly this thing, which suggests that users should exactly

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

Great timing! Last week I was trying to emulate a certain Rust example in Python. Rust has a way to implement families of classes without subclassing, which I think could be a great addition to Python someday. I'll explain below. Here is a Rust example (https://youtu.be/WDkv2cKOxx0?t=3795) that

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

On 24.06.2020 20:08, Guido van Rossum wrote: > On Wed, Jun 24, 2020 at 7:27 AM M.-A. Lemburg > wrote: > > Wow, so 19 years after PEP 275, we are indeed getting a switch > statement. Nice :-) > > > Indeed. Fortunately there are now some better ideas to steal from

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

Guido van Rossum wrote: > So why not .get(key, )? You can reuse the sentinel, and this way > it's a single call instead of two -- e.g. the code in Mapping implements both > __contains__() and get() by calling __getitem__() and catching KeyError. Good point. Another option I've considered is

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

On Wed, Jun 24, 2020 at 7:27 AM M.-A. Lemburg wrote: > Wow, so 19 years after PEP 275, we are indeed getting a switch > statement. Nice :-) > Indeed. Fortunately there are now some better ideas to steal from other languages than C's switch. :-) Something which struck me as odd when first

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

I declare this post Off Topic. Please open another thread (preferably on python-ideas). Everybody else, please don't respond to this particular post by the OP. On Wed, Jun 24, 2020 at 11:12 AM pylang wrote: > Great timing! Last week I was trying to emulate a certain Rust example in > Python. >

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

On Wed, Jun 24, 2020 at 2:56 AM Greg Ewing wrote: > One other thing that the PEP doesn't make clear -- is it possible > to combine '=' and ':=' to match a keyword argument with a sub > pattern and capture the result? I.e. can you write > > case Spam(foo = foo_value := Blarg()): > > ? > The

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

On Wed, Jun 24, 2020 at 11:05 AM Brandt Bucher wrote: > Guido van Rossum wrote: > > IIUC the pattern matching uses either .get(key, ) or > .__contains__(key) followed by .__getitem__(key). Neither of those will > auto-add the item to a defaultdict (and the Mapping protocol supports > both).

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

On Wed, Jun 24, 2020 at 3:02 AM Chris Jerdonek wrote: > I have an exploratory question. In this section: > > The alternatives may bind variables, as long as each alternative binds the >> same set of variables (excluding _). For example: >> match something: >> ... >> case Foo(arg=x) |

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

On Tue, Jun 23, 2020 at 11:27 PM Emily Bowman wrote: > I wonder if it's time to officially designate _ as a reserved name. Alas, it's too late for that. The i18n community uses _("message text") to mark translatable text. You may want to look into the gettext stdlib module. -- --Guido van

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

Guido van Rossum wrote: > IIUC the pattern matching uses either .get(key, ) or > .__contains__(key) followed by .__getitem__(key). Neither of those will > auto-add the item to a defaultdict (and the Mapping protocol supports both). > @Brandt: what does your implementation currently do? Do you

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

> On 24 Jun 2020, at 19:14, Guido van Rossum wrote: > > (Jakub, next time please trim the original post from your quote to what's > necessary.) > Apologies, unintentional, I was replying from the web interface since I wasn’t subscribed to this gorup when the thread was started and I clicked

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

On Wed, 24 Jun 2020 at 17:22, Victor Stinner wrote: [...] > The question becomes: how to promote the limited C API? Should it > become the default, rather than an opt-in option? > It would be interesting to find out what is the performance impact of using limited C API, vs normal API, on some

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

(Jakub, next time please trim the original post from your quote to what's necessary.) On Wed, Jun 24, 2020 at 9:11 AM wrote: > Wow, I totally didn't see this coming, not after seeing what seems like a > lot of rejected ideas on this topic (there was at least one PEP already > that proposed

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

As a tangential follow-up to my thought that _"the `:=` walrus operator seems to be usable as a substitute for new syntax"_, you can actually build a seemingly complete (if somewhat error-prone) _run-time_ pattern matching API using it:

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

> On 24 Jun 2020, at 17:57, mi...@drach.uk wrote: > > To me match also sound confusing as a keyword. You don't match things to > cases in English. > Maybe match x: against 1? https://idioms.thefreedictionary.com/match+against > > match point: >against (x, 1): >... >against

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

On 06/24/2020 08:57 AM, mi...@drach.uk wrote: To me match also sound confusing as a keyword. You don't match things to cases in English. Maybe match x: against 1? https://idioms.thefreedictionary.com/match+against Python uses English words, but is not English. Having said that, you can

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

On 2020-06-24 13:37, Antoine Pitrou wrote: On Wed, 24 Jun 2020 21:54:24 +1200 Greg Ewing wrote: On 24/06/20 5:20 am, Antoine Pitrou wrote: > suddently `Point(x, 0)` means something entirely > different (it doesn't call Point.__new__, it doesn't lookup `x` in the > locals or globals...).

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

On Wed, Jun 24, 2020 at 8:26 AM Eric Wieser wrote: > Thanks for the reply. > > Independent of whether the spelling is encouraged, does the PEP in its > current form consider `(name := _)` to be legal, or is `_` forbidden on the > RHS of a `:=` by a similar argument to forbidding `_` in `**_`? >

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

Better yet: given point: as (x, 1): ... as (1, y): ... as None: ... ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org

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

Le mer. 24 juin 2020 à 16:20, Stefan Behnel a écrit : > Note, I understand the difference between ABI and API. Keeping > PyTuple_GET_ITEM() a macro or inline function can break the ABI at some > point once PyTupleObject changes in an incompatible way in Py3.14, and it > may do different things in

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

To me match also sound confusing as a keyword. You don't match things to cases in English. Maybe match x: against 1? https://idioms.thefreedictionary.com/match+against match point: against (x, 1): ... against (1, y): ... Better yet it feels to me to have: handle point:

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

Guido van Rossum wrote: > I'm happy to present a new PEP for the python-dev community to review. This > is joint work with Brandt Bucher, Tobias Kohn, Ivan Levkivskyi and Talin. > Many people have thought about extending Python with a form of pattern > matching similar to that found in Scala,

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

I really dislike the fact that case with is instance check looks like instantiation. case Node(children=[…]) Along with checks for int or enum cases, "is instance” and attribute checks like the one above will be perceived as equality check. Basically what happens is based on context the round

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

Thanks for the reply. Independent of whether the spelling is encouraged, does the PEP in its current form consider `(name := _)` to be legal, or is `_` forbidden on the RHS of a `:=` by a similar argument to forbidding `_` in `**_`? Eric On Wed, 24 Jun 2020 at 16:12, Guido van Rossum wrote:

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

Thanks a lot for making this. I've been keeping excited since I heard this several hours ago! I'm a researcher(and also a student) in some field dedicated in the study of programming language constructs, including pattern matching. **Python Pattern Matching** is something special to me, which

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

On Wed, Jun 24, 2020 at 5:23 AM Eric Wieser wrote: > In regards to > https://www.python.org/dev/peps/pep-0622/#alternatives-for-constant-value-pattern, > was this alternative considered? > ``` > match obj: > case SomeClass(field := _): # is this already allowed by the PEP? > pass >

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

On Wed, Jun 24, 2020 at 7:30 AM Eric Nieuwland wrote: > Great PEP! > Thanks! 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. >

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

On Wed, Jun 24, 2020 at 4:05 AM Greg Ewing wrote: > On 24/06/20 11:57 am, Guido van Rossum wrote: > > Matched key-value pairs must already be present in the mapping, and not > > created > > on-the-fly by ``__missing__`` or ``__getitem__``. For example, > > ``collections.defaultdict`` instances

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

On Wed, Jun 24, 2020 at 7:40 AM Ethan Furman wrote: > Okay, I took Paul Moore's advice and went looking in existing code for > some examples, and came across the following: > > if isinstance(v, int): > # v is an offset > elif isinstance(v, str): > # v is a docstring >

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

On Tue, Jun 23, 2020 at 10:10 AM MRAB wrote: > Why are: > > case ._: > > not OK? > > In this: > > case .BLACK: > ... > case BLACK: > ... > > the first matches the value against 'BLACK' and the second succeeds and > binds the value to 'BLACK'. > > Replacing

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

On 24.06.2020 16:27, M.-A. Lemburg wrote: > Wow, so 19 years after PEP 275, we are indeed getting a switch > statement. Nice :-) > > Something which struck me as odd when first scanning through the PEP > is the default case compared to other Python block statements: > > match something: >

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

Wow, so 19 years after PEP 275, we are indeed getting a switch statement. Nice :-) Something which struck me as odd when first scanning through the PEP is the default case compared to other Python block statements: match something: case 0 | 1 | 2: print("Small number") case [] |

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

On 06/23/2020 09:01 AM, Guido van Rossum wrote: PEP 622 Okay, I took Paul Moore's advice and went looking in existing code for some examples, and came across the following: if isinstance(v, int): # v is an offset elif isinstance(v, str): # v is a docstring elif

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

Wow, this looks fantastic, I've wanted this for a long time! I really appreciate the work that has been put here. As a bit of context for this and future emails, I fury wanted to say: * I'm strongly positive about this even if I propose changes * I've explored a bit on my own how to do this, so

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

Great PEP! 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. Not a native speaker I don’t have a reasonable alternative, though.

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

Victor Stinner schrieb am 24.06.20 um 02:14: > Le mar. 23 juin 2020 à 16:56, Stefan Behnel a écrit : >>> Members of ``PyObject`` and ``PyTupleObject`` structures have not >>> changed since the "Initial revision" commit (1990) >> >> While I see an advantage in hiding the details of PyObject

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

Hello everyone, this is my first crack at commenting on a PEP, so apologies for mistaking any developer colloquialisms, or if this is the wrong channel to go through. In a nutshell, I was mulling over my initial difficulty in understanding name patterns and had the thought of ‘declaring’

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

On 23/06/2020 17:01, Guido van Rossum wrote: I'm happy to present a new PEP for the python-dev community to review. This is joint work with Brandt Bucher, Tobias Kohn, Ivan Levkivskyi and Talin. Can I just say thanks for all this work. I really like the concept, but like everyone else I have

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

On Wed, 24 Jun 2020 21:54:24 +1200 Greg Ewing wrote: > On 24/06/20 5:20 am, Antoine Pitrou wrote: > > suddently `Point(x, 0)` means something entirely > > different (it doesn't call Point.__new__, it doesn't lookup `x` in the > > locals or globals...). > > This is one reason I would rather see

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

A cursory search of this thread suggests that no one has mentioned this yet, but apologies if I missed one of the existing replies about this. In regards to https://www.python.org/dev/peps/pep-0622/#alternatives-for-constant-value-pattern, was this alternative considered? ``` match obj:

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

On Wed, 24 Jun 2020 at 11:44, Greg Ewing wrote: > Another possibility would to be allow cases to share the same > suite by stacking them: > > case 401: > case 402: > case 403: >... I feel as though this could be useful (although I don't have a specific use case in mind). The

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

On 24/06/20 11:57 am, Guido van Rossum wrote: Matched key-value pairs must already be present in the mapping, and not created on-the-fly by ``__missing__`` or ``__getitem__``.  For example, ``collections.defaultdict`` instances will only match patterns with keys that were already present when

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

On 24/06/20 9:31 am, Chris Angelico wrote: I can't find it among the rejected alternatives, but was it considered to use "..." as the wildcard, rather than "_"? It currently has a value as an expression, so you might want to match against it. (I don't think the syntax in the PEP currently

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

  2) Use comma as the separator - this is already legal syntax too, but IMO it reads more naturally.   (And IIRC there are already contexts where brackets are necessary to indicate a tuple.) This would be my preferred option. Another possibility would to be allow cases to share the same

[Python-Dev] Re: Draft PEP: Remove wstr from Unicode

I commented https://github.com/python/peps/pull/1462 as a review. Le mer. 24 juin 2020 à 10:21, Inada Naoki a écrit : > Do you mean APIs relating to Py_UNICODE, but not relating to > wstr nor legacy Unicode? (e.g. PyLong_FromUnicode, PyUnicode_Encode, etc...) > > We can remove them one-by-one

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

On Tue, Jun 23, 2020 at 9:12 AM Guido van Rossum wrote: > I'm happy to present a new PEP for the python-dev community to review. > This is joint work with Brandt Bucher, Tobias Kohn, Ivan Levkivskyi and > Talin. > ... > I'll mostly let the PEP speak for itself: > - Published:

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

On 24/06/20 5:20 am, Antoine Pitrou wrote: suddently `Point(x, 0)` means something entirely different (it doesn't call Point.__new__, it doesn't lookup `x` in the locals or globals...). This is one reason I would rather see something explicitly marking names to be bound, rather than making the

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

On Tue, 23 Jun 2020 14:56:47 -0700 Barry Warsaw wrote: > On Jun 23, 2020, at 14:34, Richard Levasseur wrote: > > > I agree with not having flat indentation. I think having "case" indented > > from "match" makes it more readable overall. > > I don’t know whether my suggestion to use `match:`

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

On Wed, 24 Jun 2020 at 07:40, Ethan Furman wrote: > Second premise: there is no practical difference between > > match color: > case BLACK: > # do stuff > > and > > match color: > case _: > BLACK = color > # do stuff You've

[Python-Dev] Re: Draft PEP: Remove wstr from Unicode

On Tue, Jun 23, 2020 at 6:31 PM Victor Stinner wrote: > > Le mar. 23 juin 2020 à 04:02, Inada Naoki a écrit : > > Legacy unicode representation is using wstr so legacy unicode support > > is removed with wstr. > > PyUnicode_READY() will be no-op when wstr is removed. We can remove > > calling

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

On 06/23/2020 10:11 PM, Ethan Furman wrote: As others have noted, the leading dot to disambiguate between a name assignment and a value check is going to be a problem. I suspect I wasn't as clear as I could have been, so let me try again (along with some thinking-out-loud...). First

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

On Tue, Jun 23, 2020 at 10:59 PM Rob Cliffe via Python-Dev < python-dev@python.org> wrote: > > >> I also (with others) prefer `else:` or perhaps `case else:` to using > >> the`_` variable. > >> The latter is obscure, and woudn't sit well with code that already > >> uses that variable for its own

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

On Wed, Jun 24, 2020 at 3:49 PM Ethan Furman wrote: > > On 06/23/2020 10:31 PM, Chris Angelico wrote: > > On Wed, Jun 24, 2020 at 3:21 PM Ethan Furman wrote: > >> On 06/23/2020 09:01 AM, PEP 622 wrote: > >> > >>> from enum import Enum > >>> > >>> class Color(Enum): > >>> BLACK = 1 > >>>

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

I also (with others) prefer `else:` or perhaps `case else:` to using the`_` variable. The latter is obscure, and woudn't sit well with code that already uses that variable for its own purposes. I think that's done for consistency. '_' is a wildcard and you can have:     case (_, _): to