[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

Nick Coghlan doesn't want to ever be having conversations about why "case True:" doesn't behave the same way as "case some.attr.referring.to.true:". Guido thinks that it strange enough that you won't see it. I agree that it is odd to define a complicated alias for True, but it isn't so odd to h

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

.. Also will matching ever extend into the Typing universe? In what way do you have in mind? With protocol support baked into PEP 634 that already ties into type hints. -Brett . thanks for the answers; the only one missing is whether there is an actual bestiary of example

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

(For people who fail to find any mention of protocols in PEP 634, Protocols (PEP 544) can be used (with the @runtime decorator) to override isinstance(), and class patterns are defined to use isinstance() for the class check.) On Wed, Nov 18, 2020 at 11:50 AM Brett Cannon wrote: > > > On Wed, No

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On Wed, Nov 18, 2020 at 1:25 AM Robin Becker wrote: > Is there a bestiary of examples for the current pattern matching > proposal(s)? > > It seems I don't have a good handle on how one matches simple tests like > callability, Doable using protocols. > function signatures, I don't think that

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On 6/11/20 4:54 am, Steven D'Aprano wrote: On Wed, Nov 04, 2020 at 12:15:08PM +1300, Greg Ewing wrote: If "_" is a non-binding wildcard, linters will have to allow "case _, _" otherwise it might as well not be there. And then if it is later changed to be binding, Why would we want to do that?

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On Wed, Nov 04, 2020 at 12:15:08PM +1300, Greg Ewing wrote: > If "_" is a non-binding wildcard, linters will have to allow > "case _, _" otherwise it might as well not be there. And then > if it is later changed to be binding, Why would we want to do that? Apart from the backward incompatibilit

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

I think using symbols like ? and == in patterns looks stylistically ugly, and unintuitive, albeit more explicit. I, too, would rather have pattern matching more explicit, but it shouldn't need to be so ugly (yes, I know, ugly is a subjective term, so be it). I would propose that, opposite to what

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

> On 3 Nov 2020, at 16:36, Paul Svensson wrote: > > On Tue, 3 Nov 2020, Greg Ewing wrote: > >> On 3/11/20 11:01 am, Ethan Furman wrote: >> >>> I believe supporting >>> >>> case x, x # look ma! no guard! >>> is a possible future enhancement. >> >> In which case there will be a need f

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On Tue., 3 Nov. 2020, 8:07 am Ethan Furman, wrote: > On 11/2/20 1:52 PM, Glenn Linderman wrote: > > On 11/2/2020 1:42 PM, Guido van Rossum wrote: > >> But we feel that `case x, x` can easily be misunderstood as "a tuple of > two equal values" > > > > So what _is_ the syntax for "a tuple of two eq

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On 4/11/20 4:36 am, Paul Svensson wrote: On Tue, 3 Nov 2020, Greg Ewing wrote: once people start using "_" as a wildcard in patterns, it will be too late to go back. But will it, really ? It seems to me, that if we leave the "_" magic out, and leave "case x, x" to the linters, that leaves a c

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On 11/2/20 2:01 PM, Brandt Bucher wrote: Glenn Linderman wrote: So what _is_ the syntax for "a tuple of two equal values" ? If you’re asking about PEP 634: ``` case x, y if x == y: ``` Which is much clearer, in my opinion. Yeah, I've come 'round to this opinion as well. Let's get basic pa

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On Tue, 3 Nov 2020, Greg Ewing wrote: On 3/11/20 11:01 am, Ethan Furman wrote: I believe supporting     case x, x   # look ma!  no guard! is a possible future enhancement. In which case there will be a need for *some* kind of true "don't care" placeholder. If it's not "_" then it will hav

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On 11/3/20 1:30 AM, Federico Salerno wrote: Re: symbol for lookup Whatever happened to the proposal of using . as prefix? I think . is visible enough while being aesthetically inoffensive. Am i missing some problem or important past objection to it? Many people think . is not visible enough

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On Mon, Nov 02, 2020 at 03:31:44PM +0100, Thomas Wouters wrote: > On Sat, Oct 31, 2020 at 12:25 PM Steven D'Aprano > wrote: > > > > > I really don't get why so many people are hung up over this minuscule > > issue of giving `_` special meaning inside match statements. IMO, > > consistency with ot

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

Hello, On Tue, 3 Nov 2020 10:30:22 +0100 Federico Salerno wrote: > Re: symbol for lookup > > Whatever happened to the proposal of using . as prefix? I guess, the same that happened with the proposals to use "+" as a prefix, or proposals to change sides and use "->" (https://mail.python.org/ar

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

Re: symbol for lookup Whatever happened to the proposal of using . as prefix? If memory serves, the main objection was about it being hard to see, but is it really? We use fixed width fonts for a reason, and there are other places a dot is quite critical (has any php programmer ever mistaken a .=

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On 3/11/20 11:01 am, Ethan Furman wrote: I believe supporting     case x, x   # look ma!  no guard! is a possible future enhancement. In which case there will be a need for *some* kind of true "don't care" placeholder. If it's not "_" then it will have to be something else like "?". And we

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On Tue, Nov 3, 2020 at 8:53 AM Glenn Linderman wrote: > > On 11/2/2020 1:42 PM, Guido van Rossum wrote: > > But we feel that `case x, x` can easily be misunderstood as "a tuple > > of two equal values" > > So what _is_ the syntax for "a tuple of two equal values" ? > > case x, ?x: # comes to mind

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On 11/2/20 1:52 PM, Glenn Linderman wrote: On 11/2/2020 1:42 PM, Guido van Rossum wrote: But we feel that `case x, x` can easily be misunderstood as "a tuple of two equal values" So what _is_ the syntax for "a tuple of two equal values" ? case x, ?x:  # comes to mind (not that it is in the P

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

Glenn Linderman wrote: > So what _is_ the syntax for "a tuple of two equal values" ? If you’re asking about PEP 634: ``` case x, y if x == y: ``` Which is much clearer, in my opinion. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On 11/2/2020 1:42 PM, Guido van Rossum wrote: But we feel that `case x, x` can easily be misunderstood as "a tuple of two equal values" So what _is_ the syntax for "a tuple of two equal values" ? case x, ?x:  # comes to mind (not that it is in the PEP :)) __

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On Mon, Nov 2, 2020 at 1:14 PM Eric V. Smith wrote: > On 11/2/2020 9:31 AM, Thomas Wouters wrote: > > > > On Sat, Oct 31, 2020 at 12:25 PM Steven D'Aprano > wrote: > >> >> I really don't get why so many people are hung up over this minuscule >> issue of giving `_` special meaning inside match st

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On 11/2/2020 9:31 AM, Thomas Wouters wrote: On Sat, Oct 31, 2020 at 12:25 PM Steven D'Aprano > wrote: I really don't get why so many people are hung up over this minuscule issue of giving `_` special meaning inside match statements. IMO, consistency wi

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On Sat, Oct 31, 2020 at 12:25 PM Steven D'Aprano wrote: > > I really don't get why so many people are hung up over this minuscule > issue of giving `_` special meaning inside match statements. IMO, > consistency with other languages' pattern matching is more useful than > the ability to capture u

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On Sun, 1 Nov 2020 at 11:29, Nick Coghlan wrote: > On Sat., 31 Oct. 2020, 9:29 pm Steven D'Aprano, wrote: >> (4) Patterns which could conceivably be interpreted as assignment >> targets default to capture patterns, because that's what is normally >> wanted in pattern matching: >> >> >> case [

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On Sun., 1 Nov. 2020, 3:01 pm Guido van Rossum, wrote: > On Sat, Oct 31, 2020 at 21:48 Dan Stromberg wrote: > >> >> On Sat, Oct 31, 2020 at 9:37 PM Guido van Rossum >> wrote: >> >>> >>> I think this over-stresses the notion that users might want to override >>> the comparison operator to be use

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On Sat, Oct 31, 2020 at 21:48 Dan Stromberg wrote: > > On Sat, Oct 31, 2020 at 9:37 PM Guido van Rossum wrote: > >> >> I think this over-stresses the notion that users might want to override >> the comparison operator to be used. We only have two operators that make >> sense in this context, 'is

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On Sat, Oct 31, 2020 at 9:37 PM Guido van Rossum wrote: > > I think this over-stresses the notion that users might want to override > the comparison operator to be used. We only have two operators that make > sense in this context, 'is' and '==', and really, for almost everything you > want to do

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On Sat, Oct 31, 2020 at 6:30 PM Nick Coghlan wrote: > On Sat., 31 Oct. 2020, 9:29 pm Steven D'Aprano, > wrote: > >> >> >> >> (3) Overriding the default comparison with an explicit sigil is >> allowed: >> >> >> case ==True: >> print("True, or 1, or 1.0, or 1+0j, etc") >> >> case =

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On Sat., 31 Oct. 2020, 9:29 pm Steven D'Aprano, wrote: > > > > (3) Overriding the default comparison with an explicit sigil is > allowed: > > > case ==True: > print("True, or 1, or 1.0, or 1+0j, etc") > > case ==None: > print("None, or something weird that equals None") >

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

Hello, On Sat, 31 Oct 2020 12:16:09 + Paul Moore wrote: > On Sat, 31 Oct 2020 at 11:25, Steven D'Aprano > wrote: > > > > Thank you for the well-written PEP, although I don't agree with it. > > My response below is quite long. Here is my opinionated TL;DR: > > For what it's worth, I find

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On Sat, 31 Oct 2020 at 11:25, Steven D'Aprano wrote: > > Thank you for the well-written PEP, although I don't agree with it. My > response below is quite long. Here is my opinionated TL;DR: For what it's worth, I find your rebuttal of PEP 642 convincing, and in line with my thoughts on the matter

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

On Sat, Oct 31, 2020 at 10:22:09PM +1100, Steven D'Aprano wrote: > (1) Just get over the use of `_` for the wildcard pattern. > another identifier. Now that the parser will support soft keywords, we > should expect more cases that something that is an identifier is one > context will be a keywo

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

Thank you for the well-written PEP, although I don't agree with it. My response below is quite long. Here is my opinionated TL;DR: (1) Just get over the use of `_` for the wildcard pattern. another identifier. Now that the parser will support soft keywords, we should expect more cases that som

[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

Hi Nick and Everyone, We had actually considered a similar idea (i.e. load sigils) during the design phase of pattern matching. In the interest of having a rule that is as simple as possible, we had proposed to use a leading dot as a universal marker. Tin's example would thus have been wr