[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On 18/11/20 5:29 pm, Stephen J. Turnbull wrote: Glenn Linderman writes: > Mathematics never came up with separate symbols for equality and > assignment. Mathematics doesn't need them, until we come to an age where we do mathematics on algorithms. Even then, when mathematicians describe

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

Glenn Linderman writes: > Mathematics never came up with separate symbols for equality and > assignment. Mathematics doesn't need them, until we come to an age where we do mathematics on algorithms. It's perfectly possible to do algebra interpreting "let x = 3" as an equation of the form

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On 2020-11-16 08:54, Glenn Linderman wrote: On 11/15/2020 11:18 PM, Stephen J. Turnbull wrote: Jim J. Jewett writes: > What advantage can there be in re-using syntax to mean something > opposite to what it normally does? In math, it allows us to write "solve c = f(x) for x". That doesn't

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On 11/15/2020 11:18 PM, Stephen J. Turnbull wrote: Jim J. Jewett writes: > What advantage can there be in re-using syntax to mean something > opposite to what it normally does? In math, it allows us to write "solve c = f(x) for x". That doesn't mean "bind c to the value f(x)", it means

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

Jim J. Jewett writes: > What advantage can there be in re-using syntax to mean something > opposite to what it normally does? In math, it allows us to write "solve c = f(x) for x". That doesn't mean "bind c to the value f(x)", it means exactly the opposite. No problem here, I suppose. So

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

Matching *should* look like instantiation ... case Point(2, 4) *should* mean "Does it match the object that Point(2, 4) would create?". case Point(2, y=4) is less crucial, because they *could* rewrite the call -- but why should they have to? Changing from constants, and case

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On Sun., 15 Nov. 2020, 5:25 pm Guido van Rossum, wrote: > But Point(x as a) already has a meaning in PEP 634; it’s a positional > argument captured in x *and* in a. (Previously spelled as Point(a := x). > The phrase ‘as a’ can be added after any pattern to *also* capture it in > ‘a’. More

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

Hello, On Sun, 15 Nov 2020 00:22:01 -0500 Kyle Stanley wrote: [] > FWIW, I'd like to add my +1 to usage of "as" for spelling class > capture patterns. If you want to use "as" in spelling of class capture patterns, you don't need to worry about anything, because PEP634 already allows that:

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

Jim J. Jewett writes: > I *hope* this was a typo! If > > case Point(x=a, y=b): > > assigns to a and b (instead of x and y, as in a normal call), then > that is ... going to be very easy for me to forget, and to miss > even when I'm aware of it. I don't argue with your main point

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

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

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On Sun, Nov 15, 2020 at 1:56 AM Chris Angelico wrote: > On Sun, Nov 15, 2020 at 4:28 PM Kyle Stanley wrote: > > > > FWIW, I'd like to add my +1 to usage of "as" for spelling class capture > patterns. This is by far the clearest and easiest to read form I've seen > thus far, and I suspect that

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On Sun, Nov 15, 2020 at 4:28 PM Kyle Stanley wrote: > > FWIW, I'd like to add my +1 to usage of "as" for spelling class capture > patterns. This is by far the clearest and easiest to read form I've seen thus > far, and I suspect that it would be the easiest to explain to users already >

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On Sat, Nov 14, 2020 at 7:54 AM Nick Coghlan wrote: > On Sat, 14 Nov 2020 at 09:51, Greg Ewing > wrote: > > > > On 14/11/20 7:45 am, Brandt Bucher wrote: > > > with (using your own syntactic flavor): > > > ``` > > > case >first, *>middle, >last: > > > rebuilt = first, *middle, last > > >

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

Hello, On Fri, 13 Nov 2020 18:45:55 - "Brandt Bucher" wrote: > Paul Sokolovsky wrote: > > Use punctuation ("sigils") to mark as-binding terms. This choice > > still seems to be under-considered. (As in: it doesn't seem like > > many people, including the PEP authors, tried to say "indeed,

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On Sat, 14 Nov 2020 at 09:51, Greg Ewing wrote: > > On 14/11/20 7:45 am, Brandt Bucher wrote: > > with (using your own syntactic flavor): > > ``` > > case >first, *>middle, >last: > > rebuilt = first, *middle, last > > case {"key": >value, **>rest}: > > rebuilt = {"key": value, **rest}

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On Sat, 14 Nov 2020 at 07:55, Joao S. O. Bueno wrote: > On Fri, 13 Nov 2020 at 17:36, Jim J. Jewett wrote: >> >> I *hope* this was a typo! If >> >> case Point(x=a, y=b): >> >> assigns to a and b (instead of x and y, as in a normal call), then that is >> ... going to be very easy for me to

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On Sat, 14 Nov 2020 at 01:59, Baptiste Carvello wrote: > > Hi, > > Le 12/11/2020 à 18:55, Guido van Rossum a écrit : > > The position of PEP 622/634/535/636 authors is clear: > > well, let me first emphasize that I did *not* mean to reopen the > discussion on those PEPs, which explain and discuss

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On Fri., 13 Nov. 2020, 4:01 am Guido van Rossum, wrote: > The position of PEP 622/634/535/636 authors is clear: we see this as a > necessary feature to support using enums (e.g. Color.RED) or constants > defined in other modules (e.g. re.I) when simple switch functionality is > being migrated

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On 14/11/20 9:33 am, Jim J. Jewett wrote: I *hope* this was a typo! If case Point(x=a, y=b): assigns to a and b (instead of x and y, as in a normal call), then that is ... going to be very easy for me to forget, and to miss even when I'm aware of it. I don't think it is a typo,

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On 14/11/20 7:45 am, Brandt Bucher wrote: with (using your own syntactic flavor): ``` case >first, *>middle, >last: rebuilt = first, *middle, last case {"key": >value, **>rest}: rebuilt = {"key": value, **rest} case Point(x=>a, y=>b): rebuilt = Point(x=a, y=b) I think this is a

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On 11/13/2020 1:48 PM, Joao S. O. Bueno wrote: On Fri, 13 Nov 2020 at 17:36, Jim J. Jewett > wrote: I *hope* this was a typo!  If     case Point(x=a, y=b): assigns to a and b (instead of x and y, as in a normal call), then that is ... going to

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On Fri, 13 Nov 2020 at 17:36, Jim J. Jewett wrote: > I *hope* this was a typo! If > > case Point(x=a, y=b): > > assigns to a and b (instead of x and y, as in a normal call), then that is > ... going to be very easy for me to forget, and to miss even when I'm aware > of it. > No typo -

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

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

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On Fri, 13 Nov 2020 at 15:53, Brandt Bucher wrote: > Paul Sokolovsky wrote: > > Use punctuation ("sigils") to mark as-binding terms. This choice still > seems to be under-considered. (As in: it doesn't seem like many people, > including the PEP authors, tried to say "indeed, what if?" and feel

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

Paul Sokolovsky wrote: > Use punctuation ("sigils") to mark as-binding terms. This choice still seems > to be under-considered. (As in: it doesn't seem like many people, including > the PEP authors, tried to say "indeed, what if?" and feel thru it. I mean, > try really hard. I trust the "gang

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On Thu, Nov 12, 2020 at 11:41 PM Paul Sokolovsky wrote: > Hello, > > On Thu, 12 Nov 2020 12:51:19 -0800 > Guido van Rossum wrote: > > > I have a meta-observation. Clearly there are too many cooks here. The > > same suggestions keep getting brought up. We will never converge on a > > design this

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

Hi, Le 12/11/2020 à 18:55, Guido van Rossum a écrit : > The position of PEP 622/634/535/636 authors is clear: well, let me first emphasize that I did *not* mean to reopen the discussion on those PEPs, which explain and discuss their design choices thoroughly (even better since the rewrite,

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

Hello, On Fri, 13 Nov 2020 21:51:49 +1100 Steven D'Aprano wrote: > > match foo: > > case ("foo", >val1): > > ... > > case ("bar", >val2): > > ... > > > 1. Much more intuitive for beginners. (If Python adopts it, I see > > other "user-friendly" languages adopting the

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On Thu, Nov 12, 2020 at 09:40:02PM +0300, Paul Sokolovsky wrote: > match foo: > case ("foo", >val1): > ... > case ("bar", >val2): > ... > 1. Much more intuitive for beginners. (If Python adopts it, I see > other "user-friendly" languages adopting the same pattern in the

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

Hello, On Thu, 12 Nov 2020 12:51:19 -0800 Guido van Rossum wrote: > I have a meta-observation. Clearly there are too many cooks here. The > same suggestions keep getting brought up. We will never converge on a > design this way. Right, it's not a Python decision unless it's forced thru like

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

Hello, On Thu, 12 Nov 2020 20:19:13 + MRAB wrote: [] > > Question of "what to mark with sigils - terms-used-as-values or > > terms-used-for-capturing" is orthogonal to the question of "what to > > use as match-all symbol", though I understand the desire to > > repurpose the same symbol for

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On Thu, Nov 12, 2020 at 4:25 PM Greg Ewing wrote: > On 13/11/20 8:21 am, Paul Sokolovsky wrote: > > The current stage is to accept > > the fact that "mark capturing terms" is *very viable* alternative to > > "mark terms to use as values" ... But people > > behind PEPs keep ignoring that choice -

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On 13/11/20 9:19 am, MRAB wrote: I'd still want to list "as" as another possibility, the advantage being that it's already used for binding elsewhere. Only where it makes English grammatical sense, though, which it doesn't unless there's something on both sides. -- Greg

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On 13/11/20 8:21 am, Paul Sokolovsky wrote: The current stage is to accept the fact that "mark capturing terms" is *very viable* alternative to "mark terms to use as values" ... But people behind PEPs keep ignoring that choice - silently, or with minimal consideration/commentary. Their stated

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

I have a meta-observation. Clearly there are too many cooks here. The same suggestions keep getting brought up. We will never converge on a design this way. At this point the only thing to do is to wait for the Steering Council. I am not going to argue about the merits of any more specific ideas

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

On 2020-11-12 19:21, Paul Sokolovsky wrote: Hello, [Re-routed back to python-dev.] On Thu, 12 Nov 2020 20:04:57 +0100 Piotr Duda wrote: [] > match foo: > case ("foo", >val1): > ... > case ("bar", >val2): > ... > I agree with that, though I would prefer using

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

Hello, [Re-routed back to python-dev.] On Thu, 12 Nov 2020 20:04:57 +0100 Piotr Duda wrote: [] > > match foo: > > case ("foo", >val1): > > ... > > case ("bar", >val2): > > ... > > > > I agree with that, though I would prefer using other symbol than > (? > or $), one

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

czw., 12 lis 2020 o 19:41 Paul Sokolovsky napisał(a): > > Hello, > > On Thu, 12 Nov 2020 09:55:10 -0800 > Guido van Rossum wrote: > > > The position of PEP 622/634/535/636 authors is clear: we see this as a > > necessary feature to support using enums (e.g. Color.RED) or constants > > defined in

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

Hello, On Thu, 12 Nov 2020 09:55:10 -0800 Guido van Rossum wrote: > The position of PEP 622/634/535/636 authors is clear: we see this as a > necessary feature to support using enums (e.g. Color.RED) or constants > defined in other modules (e.g. re.I) when simple switch functionality > is being

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

The position of PEP 622/634/535/636 authors is clear: we see this as a necessary feature to support using enums (e.g. Color.RED) or constants defined in other modules (e.g. re.I) when simple switch functionality is being migrated from literals (e.g. case 404) to named constants (e.g. case

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

Hi, Le 08/11/2020 à 07:47, Nick Coghlan a écrit : > Hi folks, > > I have updated PEP 642 significantly based on the feedback received > over the past week. > > [...] a change that I feel is insufficiently discussed is the choice to have "attr_constraint" as an inferred constraint. I can think