Re: [Python-Dev] assignment expressions: an alternative proposal

Nick Coghlan wrote: I'd be +0 on an "is=" spelling But "is=' looks like some kind of comparison operator. This seems even more conusing to me. -- Greg ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] assignment expressions: an alternative proposal

On 2018-04-24 23:32, Cameron Simpson wrote: On 24Apr2018 08:51, Ethan Furman wrote: When I compare to variables from outer scopes they *usually* are on the *right* side of '=='. You mean something like if 2 == x: ? I never write code like that, and I haven't seen it,

Re: [Python-Dev] assignment expressions: an alternative proposal

On 24Apr2018 08:51, Ethan Furman wrote: When I compare to variables from outer scopes they *usually* are on the *right* side of '=='. You mean something like if 2 == x: ? I never write code like that, and I haven't seen it, either. Just to this, I also never write

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 10:29:11PM +0100, Anthony Flury via Python-Dev wrote: > If Python is going to do assignment expressions we shouldn't overload > parens in my opinion - we should have a separate operator - doing this > avoids needing to exclude rebinding, and makes such expressions >

Re: [Python-Dev] assignment expressions: an alternative proposal

On Wed, Apr 25, 2018 at 7:29 AM, Anthony Flury via Python-Dev wrote: > On 24/04/18 17:11, Yury Selivanov wrote: >> >> On Tue, Apr 24, 2018 at 12:03 PM, Ethan Furman wrote: >> [..] >>> >>> But I do write this: >>> >>>def wrapper(func, some_value):

Re: [Python-Dev] assignment expressions: an alternative proposal

On 24/04/18 17:11, Yury Selivanov wrote: On Tue, Apr 24, 2018 at 12:03 PM, Ethan Furman wrote: [..] But I do write this: def wrapper(func, some_value): value_I_want = process(some_value) def wrapped(*args, **kwds): if value_I_want == 42: ...

Re: [Python-Dev] assignment expressions: an alternative proposal

On Apr 24, 2018, at 06:55, Antoine Pitrou wrote: > > If the ambition is to find a piece of syntax that reads as "binds", > then we can use a variation on the FLUFL operator: "<->". FLUFL Override Approved! -Barry signature.asc Description: Message signed with OpenPGP

Re: [Python-Dev] assignment expressions: an alternative proposal

On Wed, Apr 25, 2018 at 2:57 AM, Steven D'Aprano wrote: > On Wed, Apr 25, 2018 at 02:42:08AM +1000, Chris Angelico wrote: > >> > from math import * >> > process(arg, (pi = 1), pi+1) # allowed > > >> That's not allowed at local scope (at least, it's not allowed at >>

Re: [Python-Dev] assignment expressions: an alternative proposal

On Wed, Apr 25, 2018 at 02:42:08AM +1000, Chris Angelico wrote: > > from math import * > > process(arg, (pi = 1), pi+1) # allowed > That's not allowed at local scope (at least, it's not allowed at > function scope - is there any other "local scope" at which it is > allowed?). Of

Re: [Python-Dev] assignment expressions: an alternative proposal

On Wed, Apr 25, 2018 at 2:23 AM, Steven D'Aprano wrote: > On Tue, Apr 24, 2018 at 11:25:58AM -0400, Yury Selivanov wrote: > >> No, it doesn't. The check is performed during compile phase, and >> Python does not unroll loops. Anyways, read below. > > What does unrolling loops

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 11:35:20AM -0400, Yury Selivanov wrote: > Yes, it would force users to come up with better names *iff* they want > to use this new sugar: > > if (first_target = get_first_candidate()) ... > elif (second_target = get_second_candidate()) ... They're not better names.

Re: [Python-Dev] assignment expressions: an alternative proposal

On Wed, Apr 25, 2018 at 2:28 AM, Steven D'Aprano wrote: > On Tue, Apr 24, 2018 at 10:58:24AM -0400, Yury Selivanov wrote: > >> Since 'diff' and 'g' must be new names according to rule (3), those >> who read the code will notice that both were not previously bound. > > How am

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 11:25:58AM -0400, Yury Selivanov wrote: > No, it doesn't. The check is performed during compile phase, and > Python does not unroll loops. Anyways, read below. What does unrolling loops have to do with anything? And besides, loop unrolling is an implementation detail --

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 10:58:24AM -0400, Yury Selivanov wrote: > Since 'diff' and 'g' must be new names according to rule (3), those > who read the code will notice that both were not previously bound. How am I supposed to notice that they've never been bound without carefully reading through

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 12:03 PM, Ethan Furman wrote: [..] > But I do write this: > > def wrapper(func, some_value): > value_I_want = process(some_value) > def wrapped(*args, **kwds): > if value_I_want == 42: > ... But this pattern is more rare than

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 11:58 AM, Chris Angelico wrote: > On Wed, Apr 25, 2018 at 1:49 AM, Yury Selivanov > wrote: >> On Tue, Apr 24, 2018 at 11:34 AM, Steven D'Aprano >> wrote: [..] >>> There's no advantage to using

Re: [Python-Dev] assignment expressions: an alternative proposal

On Wed, Apr 25, 2018 at 1:56 AM, Yury Selivanov wrote: > On Tue, Apr 24, 2018 at 11:51 AM, Ethan Furman wrote: > >>> When I compare to variables from outer scopes they *usually* are on >>> the *right* side of '=='. >> >> >> You mean something like >>

Re: [Python-Dev] assignment expressions: an alternative proposal

On 04/24/2018 08:56 AM, Yury Selivanov wrote: On Tue, Apr 24, 2018 at 11:51 AM, Ethan Furman wrote: When I compare to variables from outer scopes they *usually* are on the *right* side of '=='. You mean something like if 2 == x: ? I never write code like that, and

Re: [Python-Dev] assignment expressions: an alternative proposal

On Wed, Apr 25, 2018 at 1:49 AM, Yury Selivanov wrote: > On Tue, Apr 24, 2018 at 11:34 AM, Steven D'Aprano wrote: >> On Tue, Apr 24, 2018 at 11:05:57AM -0400, Yury Selivanov wrote: >> >>> Well, `my_func(a=(b:=foo))` or `my_func(b:=foo)` are also

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 11:51 AM, Ethan Furman wrote: >> When I compare to variables from outer scopes they *usually* are on >> the *right* side of '=='. > > > You mean something like > > if 2 == x: > > ? I never write code like that, and I haven't seen it, either. Hm. I

Re: [Python-Dev] assignment expressions: an alternative proposal

On 25 April 2018 at 01:35, Yury Selivanov wrote: > On Tue, Apr 24, 2018 at 11:31 AM, Nick Coghlan wrote: >> I *do* think the "no name rebinding except in a while loop header" >> restriction would be annoying for the if/elif use case and the while >>

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 11:34 AM, Steven D'Aprano wrote: > On Tue, Apr 24, 2018 at 11:05:57AM -0400, Yury Selivanov wrote: > >> Well, `my_func(a=(b:=foo))` or `my_func(b:=foo)` are also barely >> readable to my eye. > > There's no advantage to using binding-expressions unless

Re: [Python-Dev] assignment expressions: an alternative proposal

On 04/24/2018 08:35 AM, Yury Selivanov wrote: Yes, it would force users to come up with better names *iff* they want to use this new sugar: if (first_target = get_first_candidate()) ... elif (second_target = get_second_candidate()) ... And then the common code below that only cares

Re: [Python-Dev] assignment expressions: an alternative proposal

On 04/24/2018 08:19 AM, Yury Selivanov wrote: Yes, because I'm trying to think about this from a pragmatic side of things. My question to myself: "what syntax could I use that would prevent me from making '=' vs '==' mistake when I code?" To me, the answer is that I usually want to compare

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 11:28 AM, Chris Angelico wrote: > On re-thinking this, I think the distinction IS possible, but (a) only > in function/class scope, not at global; and (b) would be defined in > terms of lexical position, not run-time. For instance: > > def f(): > (a

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 11:27 AM, Steven D'Aprano wrote: > On Tue, Apr 24, 2018 at 11:03:35AM -0400, Yury Selivanov wrote: > >> My point was that when you see lots of '=' and ':=' used at the >> statement level, one might try to write "if x = 1" instead of "if x := >> 1" --

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 11:05:57AM -0400, Yury Selivanov wrote: > Well, `my_func(a=(b:=foo))` or `my_func(b:=foo)` are also barely > readable to my eye. There's no advantage to using binding-expressions unless you're going to re-use the name you just defined, and that re-use will give you a

Re: [Python-Dev] assignment expressions: an alternative proposal

On Wed, Apr 25, 2018 at 1:15 AM, Steven D'Aprano wrote: > By the way, the check for existing variables cannot help to be either > incomplete or incorrect if you try to do it at compile time: > > > from module import * > (x = 2) # allowed or not allowed? > > > If you

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 11:31 AM, Nick Coghlan wrote: > On 25 April 2018 at 00:54, Eric Snow wrote: >> Regardless, your 3 rules would benefit either syntax. Nick may have a >> point that the rules might be an excessive burden, but I don't think

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 11:03:35AM -0400, Yury Selivanov wrote: > My point was that when you see lots of '=' and ':=' used at the > statement level, one might try to write "if x = 1" instead of "if x := > 1" -- boom, we have an unexpected SyntaxError for some users. That's a *good* thing. They

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 11:15 AM, Steven D'Aprano wrote: [..] >> >> 3. Most importantly: it is *not* allowed to mask names in the current >> >> local scope. > > That means you can't rebind existing variables. That means you can't > rebind to the same variable in a loop. No,

Re: [Python-Dev] assignment expressions: an alternative proposal

On 25 April 2018 at 00:54, Eric Snow wrote: > Regardless, your 3 rules would benefit either syntax. Nick may have a > point that the rules might be an excessive burden, but I don't think > it's too big a deal since the restrictions are few (and align with the > most

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 11:07 AM, Chris Angelico wrote: [..] > x = 1 > if (x = 2): ... > > This, according to your proposal, raises SyntaxError - not because a > comparison was wanted and an assignment was made, but because the name > already had a value. And, even worse, this

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 09:50:34AM -0400, Yury Selivanov wrote: > On Tue, Apr 24, 2018 at 9:46 AM, Nick Coghlan wrote: > > On 24 April 2018 at 23:38, Yury Selivanov wrote: > >> I propose to use the following syntax for assignment expressions: > >> >

Re: [Python-Dev] assignment expressions: an alternative proposal

On Wed, Apr 25, 2018 at 12:58 AM, Yury Selivanov wrote: > On Tue, Apr 24, 2018 at 10:49 AM, Paul Moore wrote: > [..] 3. Most importantly: it is *not* allowed to mask names in the current local scope. >>> >>> While I agree this would be

Re: [Python-Dev] assignment expressions: an alternative proposal

On Wed, Apr 25, 2018 at 1:03 AM, Yury Selivanov wrote: > On Tue, Apr 24, 2018 at 10:56 AM, Chris Angelico wrote: > [..] >>> A lot of other questions arise though. PEP 572 proposes: >>> >>> a = 1 # assignment >>> a := 1 # also assignment >>> (a := 1)

Re: [Python-Dev] assignment expressions: an alternative proposal

On 24 April 2018 at 15:58, Yury Selivanov wrote: > On Tue, Apr 24, 2018 at 10:49 AM, Paul Moore wrote: > [..] 3. Most importantly: it is *not* allowed to mask names in the current local scope. >>> >>> While I agree this would be unambiguous

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 10:54 AM, Anthony Flury via Python-Dev wrote: [..] > As discussed previously by others on this exact proposals, you now have the > issue of confusion when using keyword arguments : *my_func(a = b)* : > clearly that is a call to `my_func' where

Re: [Python-Dev] assignment expressions: an alternative proposal

On Wed, Apr 25, 2018 at 12:54 AM, Anthony Flury via Python-Dev wrote: > As discussed previously by others on this exact proposals, you now have the > issue of confusion when using keyword arguments : *my_func(a = b)* : > clearly that is a call to `my_func' where argument a

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 10:49 AM, Paul Moore wrote: [..] >>> 3. Most importantly: it is *not* allowed to mask names in the current >>> local scope. >> >> While I agree this would be unambiguous to a computer, I think for >> most humans it would be experienced as a confusing

Re: [Python-Dev] assignment expressions: an alternative proposal

Thanks for thinking this through, Yury. :) FWIW, I'm still unconvinced that an assignment expression is worth it. It's hard to say, though, without seeing how much folks would actually use it (and I don't have my own time machine unfortunately). IIRC, in the past several proposed syntax (e.g.

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 10:56 AM, Chris Angelico wrote: [..] >> A lot of other questions arise though. PEP 572 proposes: >> >> a = 1 # assignment >> a := 1 # also assignment >> (a := 1) # also assignment >> (a = 1) # error, why? > > Your third example is just the same as

Re: [Python-Dev] assignment expressions: an alternative proposal

On 24/04/18 14:50, Yury Selivanov wrote: On Tue, Apr 24, 2018 at 9:46 AM, Nick Coghlan wrote: On 24 April 2018 at 23:38, Yury Selivanov wrote: I propose to use the following syntax for assignment expressions: ( NAME = expr ) I know that it

Re: [Python-Dev] assignment expressions: an alternative proposal

On Wed, Apr 25, 2018 at 12:23 AM, Yury Selivanov wrote: > On Tue, Apr 24, 2018 at 10:07 AM, Nick Coghlan wrote: > >>> "=" is always an assignment. >>> "==" is always an equality check. >> >> That's not the distinction I meant, I meant the difficulty

Re: [Python-Dev] assignment expressions: an alternative proposal

On 25 April 2018 at 00:23, Yury Selivanov wrote: > A lot of other questions arise though. PEP 572 proposes: > > a = 1 # assignment > a := 1 # also assignment > (a := 1) # also assignment > (a = 1) # error, why? That's just the typical assignment/expression

Re: [Python-Dev] assignment expressions: an alternative proposal

On 24 April 2018 at 14:46, Nick Coghlan wrote: > On 24 April 2018 at 23:38, Yury Selivanov wrote: >> I propose to use the following syntax for assignment expressions: >> >> ( NAME = expr ) >> >> I know that it was proposed before and this idea was

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 10:07 AM, Nick Coghlan wrote: >> "=" is always an assignment. >> "==" is always an equality check. > > That's not the distinction I meant, I meant the difficulty of > explaining the discrepancies in this list: > > a = 1 # Assignment > (a = 1) # Also

Re: [Python-Dev] assignment expressions: an alternative proposal

On 24 April 2018 at 23:50, Yury Selivanov wrote: > On Tue, Apr 24, 2018 at 9:46 AM, Nick Coghlan wrote: >> On 24 April 2018 at 23:38, Yury Selivanov wrote: >>> I propose to use the following syntax for assignment expressions:

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, 24 Apr 2018 23:46:34 +1000 Nick Coghlan wrote: > On 24 April 2018 at 23:38, Yury Selivanov wrote: > > I propose to use the following syntax for assignment expressions: > > > > ( NAME = expr ) > > > > I know that it was proposed before and

Re: [Python-Dev] assignment expressions: an alternative proposal

On Tue, Apr 24, 2018 at 9:46 AM, Nick Coghlan wrote: > On 24 April 2018 at 23:38, Yury Selivanov wrote: >> I propose to use the following syntax for assignment expressions: >> >> ( NAME = expr ) >> >> I know that it was proposed before and this

Re: [Python-Dev] assignment expressions: an alternative proposal

On 24 April 2018 at 23:38, Yury Selivanov wrote: > I propose to use the following syntax for assignment expressions: > > ( NAME = expr ) > > I know that it was proposed before and this idea was rejected, because > accidentally using '=' in place of '==' is a pain