Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-18 Thread Antoine Pitrou
Agreed with Paul and Steve. A lot of work seems to have gone into the PEP (congratulations for that), but still the feature brings little to no additional power to the language while making it more complex. -1 from me. Regards Antoine. On Tue, 17 Apr 2018 06:55:58 -0700 Steve Dower

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-18 Thread Oleg Broytman
On Wed, Apr 18, 2018 at 09:26:17PM +, "Gregory P. Smith" wrote: > On Wed, Apr 18, 2018 at 11:04 AM Barry Warsaw wrote: > > Since I can???t have ???>>??? or ???<>??? back, I propose ???===???. > > 8 of course. to "match" what merge conflict markers

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-18 Thread Guido van Rossum
On Wed, Apr 18, 2018 at 11:17 AM, Chris Angelico wrote: > On Thu, Apr 19, 2018 at 2:18 AM, Guido van Rossum > wrote: > > On Wed, Apr 18, 2018 at 7:35 AM, Chris Angelico > wrote: > >> > >> On Wed, Apr 18, 2018 at 11:58 PM, Guido van Rossum

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-18 Thread Gregory P. Smith
On Wed, Apr 18, 2018 at 11:04 AM Barry Warsaw wrote: > On Apr 18, 2018, at 10:43, MRAB wrote: > > > Some languages use '=' for assignment, others for equality, but do you > know of a language that uses ':=' for equality' or '==' for assignment? > >

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-18 Thread Chris Angelico
On Thu, Apr 19, 2018 at 6:26 AM, Barry Warsaw wrote: > On Apr 18, 2018, at 11:17, Chris Angelico wrote: > >> At the moment, it isn't aware of 'del’. > > I don’t know if it’s relevant to the current discussion, but don’t forget > about implicit dels: > > def

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-18 Thread Barry Warsaw
On Apr 18, 2018, at 11:17, Chris Angelico wrote: > At the moment, it isn't aware of 'del’. I don’t know if it’s relevant to the current discussion, but don’t forget about implicit dels: def foo(): x = 1 try: 1/0 except ZeroDivisionError as x: pass

Re: [Python-Dev] Timing for removing legacy Unicode APIs deprecated by PEP 393

2018-04-18 Thread Serhiy Storchaka
13.04.18 16:27, INADA Naoki пише: Then, I want to reschedule the removal of these APIs. Can we remove them in 3.8? 3.9? or 3.10? I prefer sooner as possible. I suppose that many users will start porting to Python 3 only in 2020, after 2.7 EOL. After that time we shouldn't support

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-18 Thread Chris Angelico
On Thu, Apr 19, 2018 at 2:18 AM, Guido van Rossum wrote: > On Wed, Apr 18, 2018 at 7:35 AM, Chris Angelico wrote: >> >> On Wed, Apr 18, 2018 at 11:58 PM, Guido van Rossum >> wrote: >> > I can't tell from this what the PEP actually says

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-18 Thread Barry Warsaw
On Apr 18, 2018, at 10:43, MRAB wrote: > Some languages use '=' for assignment, others for equality, but do you know > of a language that uses ':=' for equality' or '==' for assignment? Clearly we should take a page from the ternary operator and make the assignment

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-18 Thread MRAB
On 2018-04-17 22:44, Greg Ewing wrote: Paul Moore wrote: the next question will likely be "so why does = exist at all?" And if we decide to make ':=' the official assigment operator and deprectate '=', the next question will be "Why do we have '==' instead of '='?" Some languages use '=' for

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-18 Thread Tim Peters
[Tim] >> And, for some reason, I find this even worse: >> >> while ((x, y) := func_returning_tuple())[1] is not None: >> ... >> >> The rub there: I gave `y` a name but can't use it in the test?! >> >> And those are the same kinds of headaches I saw over & over in my own >> "fancier"

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-18 Thread Brett Cannon
On Tue, 17 Apr 2018 at 14:53 Eric Snow wrote: > On Tue, Apr 17, 2018 at 7:55 AM, Steve Dower > wrote: > > Agree with Paul. The PEP is well thought out and well presented, but I > > really don’t think we need this in Python (and I say this as

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-18 Thread Guido van Rossum
On Wed, Apr 18, 2018 at 7:35 AM, Chris Angelico wrote: > On Wed, Apr 18, 2018 at 11:58 PM, Guido van Rossum > wrote: > > I can't tell from this what the PEP actually says should happen in that > > example. When I first saw it I thought "Gaah! What a horrible

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-18 Thread Chris Angelico
On Wed, Apr 18, 2018 at 11:58 PM, Guido van Rossum wrote: > I can't tell from this what the PEP actually says should happen in that > example. When I first saw it I thought "Gaah! What a horrible piece of > code." But it works today, and people's code *will* break if we change

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-18 Thread Guido van Rossum
On Tue, Apr 17, 2018 at 7:04 PM, Chris Angelico wrote: > On Wed, Apr 18, 2018 at 11:20 AM, Steven D'Aprano > wrote: > > On Wed, Apr 18, 2018 at 10:13:58AM +1000, Chris Angelico wrote: > > > > [regarding comprehensions] > > > >> The changes here are only to

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-18 Thread Nick Coghlan
On 18 April 2018 at 10:20, Guido van Rossum wrote: [Tim Peters wrote] >> 2. Back off and limit assignment expressions to what appears to be the >> overwhelmingly most common case motivated by looking at real code (as >> opposed to constructing examples to illustrate pitfalls &

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-18 Thread Nick Coghlan
On 18 April 2018 at 11:35, Tim Peters wrote: > And, for some reason, I find this even worse: > > while ((x, y) := func_returning_tuple())[1] is not None: > ... > > The rub there: I gave `y` a name but can't use it in the test?! > > And those are the same kinds

Re: [Python-Dev] PEP 572: Assignment Expressions

2018-04-18 Thread Nick Coghlan
On 18 April 2018 at 15:49, Jeroen Demeyer wrote: > On 2018-04-18 02:13, Chris Angelico wrote: >> >> I'm much happier promoting a full-featured assignment expression than >> something that can only be used in a limited set of situations. Is >> there reason to believe that