[Python-Dev] Re: Flexible assignment targets

2020-07-03 Thread Terry Reedy
On 7/3/2020 8:28 AM, Rhodri James wrote: On 03/07/2020 00:12, Nick Coghlan wrote: On Fri., 3 Jul. 2020, 2:27 am MRAB, wrote: match shape: try Point(x, y): ... try Rectangle(x0, y0, x1, y1, painted=True): ... I'm actually surprised at how much I like that.  It

[Python-Dev] Re: Flexible assignment targets

2020-07-03 Thread Rhodri James
On 03/07/2020 00:12, Nick Coghlan wrote: On Fri., 3 Jul. 2020, 2:27 am MRAB, wrote: IMHO, the assignment statement should remain as it is, not sometimes assign and sometimes not. There could be another form that does matching: try ?x, 0 = (4,5) Huh, this made me wonder if

[Python-Dev] Re: Flexible assignment targets

2020-07-02 Thread Rob Cliffe via Python-Dev
On 03/07/2020 00:12, Nick Coghlan wrote: On Fri., 3 Jul. 2020, 2:27 am MRAB, > wrote: IMHO, the assignment statement should remain as it is, not sometimes assign and sometimes not. There could be another form that does matching:      try

[Python-Dev] Re: Flexible assignment targets

2020-07-02 Thread Guido van Rossum
Unfortunately there are millions of ideas. The PEP authors are taking the dilemma seriously and we are deliberating what to do. On Thu, Jul 2, 2020 at 4:04 PM Nick Coghlan wrote: > On Thu., 2 Jul. 2020, 11:18 am Guido van Rossum, wrote: > >> On Wed, Jul 1, 2020 at 5:50 PM Nick Coghlan wrote:

[Python-Dev] Re: Flexible assignment targets

2020-07-02 Thread Nick Coghlan
On Fri., 3 Jul. 2020, 2:27 am MRAB, wrote: > > IMHO, the assignment statement should remain as it is, not sometimes > assign and sometimes not. > > There could be another form that does matching: > > try ?x, 0 = (4,5) > Huh, this made me wonder if "match/try" may fit people's brains

[Python-Dev] Re: Flexible assignment targets

2020-07-02 Thread Nick Coghlan
On Thu., 2 Jul. 2020, 11:18 am Guido van Rossum, wrote: > On Wed, Jul 1, 2020 at 5:50 PM Nick Coghlan wrote: > >> The key thing I'm hoping for in PEP 622 itself is that "Syntactic >> compatibility with a possible future enhancement to assignment >> statements" be considered as a constraint on

[Python-Dev] Re: Flexible assignment targets

2020-07-02 Thread Brett Cannon
It's off the table from the perspective of PEP 622 and its authors. If you want to write a competing PEP that proposes your idea that's totally fine. On Wed, Jul 1, 2020 at 8:17 PM Elliott Chen wrote: > I don't think my proposal should be off the table for scope reasons > because it requires

[Python-Dev] Re: Flexible assignment targets

2020-07-02 Thread Paul Ganssle
I think that creating a "matching assignment" operator is unnecessary at this point. I think the original point of bringing this up as part of PEP 622 is to try to suggest that the syntax for binding a value not be incompatible with a future version of Python where that same syntax can be used for

[Python-Dev] Re: Flexible assignment targets

2020-07-02 Thread MRAB
On 2020-07-02 15:48, Jim J. Jewett wrote: Guido van Rossum wrote: On Wed, Jul 1, 2020 at 5:50 PM Nick Coghlan ncogh...@gmail.com wrote: > The key thing I'm hoping for in PEP 622 itself is > that "Syntactic compatibility with a possible future > enhancement to assignment statements" be

[Python-Dev] Re: Flexible assignment targets

2020-07-02 Thread Jim J. Jewett
Guido van Rossum wrote: > On Wed, Jul 1, 2020 at 5:50 PM Nick Coghlan ncogh...@gmail.com wrote: > > The key thing I'm hoping for in PEP 622 itself is > > that "Syntactic compatibility with a possible future > > enhancement to assignment statements" be considered > > as a constraint on the syntax

[Python-Dev] Re: Flexible assignment targets

2020-07-01 Thread Elliott Chen
I don't think my proposal should be off the table for scope reasons because it requires the syntaxes to be completely unified and interchangeable, which will be impossible if the current PEP is accepted. I guess it's technically possible to still have the pattern-matching syntax be slightly

[Python-Dev] Re: Flexible assignment targets

2020-07-01 Thread Guido van Rossum
On Wed, Jul 1, 2020 at 5:50 PM Nick Coghlan wrote: > The key thing I'm hoping for in PEP 622 itself is that "Syntactic > compatibility with a possible future enhancement to assignment > statements" be considered as a constraint on the syntax for case > patterns. > That would certainly rule out

[Python-Dev] Re: Flexible assignment targets

2020-07-01 Thread Nick Coghlan
On Thu, 2 Jul 2020 at 00:50, Guido van Rossum wrote: > > Before we all get a little too excited here, I think that allowing > ``` > 1 = x > ``` > as a sneaky way of writing > ``` > assert x == 1 > ``` > would be a terrible mistake. The "two ways to do it" possibilities give me pause too, but it

[Python-Dev] Re: Flexible assignment targets

2020-07-01 Thread Guido van Rossum
We're trying to make the PEP's scope *smaller*, not larger. Let's take changes to assignment off the table. We're fully aware of the resemblance between `a, b = value` and `case a, b: ...` and we're making them behave as similar as is reasonable. On Wed, Jul 1, 2020 at 4:29 PM Daniel Moisset

[Python-Dev] Re: Flexible assignment targets

2020-07-01 Thread Daniel Moisset
If I was to do this in Python, rather than the Rust way of forbidding refutable patterns, I would put as a rule that the target must have at least one variable to bind* . It makes sense in the context that the goals of an assignment are the bindings it does, and the ValueError is an accident that

[Python-Dev] Re: Flexible assignment targets

2020-07-01 Thread Devin Jeanpierre
On Wed, Jul 1, 2020 at 11:31 AM Elliott Chen wrote: > I guess it might work in a separate PEP, but I'm also a little worried > because the current PEP would make that impossible with its subtle > incompatibilities with the existing unpacking syntax. Or even more > inconsistent, if the

[Python-Dev] Re: Flexible assignment targets

2020-07-01 Thread Daniel Moisset
On Wed, 1 Jul 2020 at 15:50, Guido van Rossum wrote: > Before we all get a little too excited here, I think that allowing > ``` > 1 = x > ``` > as a sneaky way of writing > ``` > assert x == 1 > ``` > would be a terrible mistake. > Well, we'll always have the sneaky way to check if an iterable

[Python-Dev] Re: Flexible assignment targets

2020-07-01 Thread Elliott Chen
I guess it might work in a separate PEP, but I'm also a little worried because the current PEP would make that impossible with its subtle incompatibilities with the existing unpacking syntax. Or even more inconsistent, if the assignment target syntax is extended to become similar to the match

[Python-Dev] Re: Flexible assignment targets

2020-07-01 Thread Rhodri James
On 01/07/2020 15:50, Guido van Rossum wrote: Before we all get a little too excited here, I think that allowing ``` 1 = x ``` as a sneaky way of writing ``` assert x == 1 ``` would be a terrible mistake. +1 One of Python's major virtues is that it's pretty easy to read and get the gist of

[Python-Dev] Re: Flexible assignment targets

2020-07-01 Thread Guido van Rossum
Before we all get a little too excited here, I think that allowing ``` 1 = x ``` as a sneaky way of writing ``` assert x == 1 ``` would be a terrible mistake. We already have a static way to assert that something is a string: ``` self.name: str = value ``` I don't think that we'll need another

[Python-Dev] Re: Flexible assignment targets

2020-07-01 Thread Nick Coghlan
On Thu, 2 Jul 2020 at 00:04, Elliott Chen wrote: > > I saw in the PEP that "Allow more flexible assignment targets instead" was > rejected, but I actually think it's a good idea. The current PEP means there > will be two different, subtly incompatible ways to destructure objects (match >