Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

> On 25 Apr, 2018, at 5:20 PM, Chris Angelico wrote: > > On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov > wrote: >> Just yesterday this snippet was used on python-dev to show how great the >> new syntax is: >> >> my_func(arg, buffer=(buf

[Python-Dev] Is PEP 572 really the most effective way to solve the problems it's targeting?

I have to say I'm not overly thrilled with PEP 572...it's almost odd, because if you asked me back when I first joined this list when I was 13, I would've no doubt said *YES*. But, since then, I've gone across many projects and languages, and fundamentally *I have never felt hurt by the

Re: [Python-Dev] Is PEP 572 really the most effective way to solve the problems it's targeting?

[Ryan Gonzalez ] > I have to say I'm not overly thrilled with PEP 572...it's almost odd, > because if you asked me back when I first joined this list when I was 13, I > would've no doubt said *YES*. But, since then, I've gone across many > projects and languages, and

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

Łukasz Langa wrote: What was its own assignment before now is part of the logic test. This saves on vertical whitespace but makes parsing and understanding logic tests harder. Another way to say this is that expressions are no longer restricted to being trees, but can be general DAGs, which

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

> On Apr 26, 2018, at 12:40 AM, Tim Peters wrote: > > [Raymond Hettinger ] >> After re-reading all the proposed code samples, I believe that >> adopting the PEP will make the language harder to teach to people >> who are not already software

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

Chris Angelico writes: > Additionally, naming sub-parts of a large expression can assist an > interactive debugger, providing useful display hooks and partial > results. Without a way to capture sub-expressions inline, this > would require refactoring of the original code; with assignment >

Re: [Python-Dev] Is PEP 572 really the most effective way to solve the problems it's targeting?

On April 25, 2018 11:05:04 PM Steven D'Aprano wrote: On Wed, Apr 25, 2018 at 09:36:31PM -0500, Ryan Gonzalez wrote: I have to say I'm not overly thrilled with PEP 572...it's almost odd, because if you asked me back when I first joined this list when I was 13, I would've

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

> On Apr 25, 2018, at 8:11 PM, Yury Selivanov wrote: > > FWIW I started my thread for allowing '=' in expressions to make sure that > we fully explore that path. I don't like ':=' and I thought that using '=' > can make the idea more appealing to myself and others. It

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Raymond Hettinger ] > After re-reading all the proposed code samples, I believe that > adopting the PEP will make the language harder to teach to people > who are not already software engineers. Can you elaborate on that? I've used dozens of languages over the

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Thu, Apr 26, 2018 at 05:22:58PM +1200, Greg Ewing wrote: > Łukasz Langa wrote: > >What was its own assignment before > >now is part of the logic test. This saves on vertical whitespace but makes > >parsing and understanding logic tests harder. > > Another way to say this is that expressions

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Wednesday, April 25, 2018, Łukasz Langa wrote: > > On 25 Apr, 2018, at 5:20 PM, Chris Angelico wrote: > > On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov > wrote: > > Just yesterday this snippet was used on python-dev to show how

Re: [Python-Dev] Is PEP 572 really the most effective way to solve the problems it's targeting?

On Wed, Apr 25, 2018 at 09:36:31PM -0500, Ryan Gonzalez wrote: > > > I have to say I'm not overly thrilled with PEP 572...it's almost odd, > because if you asked me back when I first joined this list when I was 13, I > would've no doubt said *YES*. I have the opposite experience: I've warmed

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Uncle T] > One language feature conspicuous by absence in newbie > confusions was, consistently, assignment expressions. Read any book > or tutorial for such a language, and you'll find very little space > devoted to them too. Well, you have an entire code style built around this feature called

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Thu, Apr 26, 2018 at 3:34 PM, Steven D'Aprano wrote: > On Thu, Apr 26, 2018 at 05:22:58PM +1200, Greg Ewing wrote: >> Łukasz Langa wrote: >> >What was its own assignment before >> >now is part of the logic test. This saves on vertical whitespace but makes >> >parsing and

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

Devin Jeanpierre writes: > Some other programming languages (thinking of Racket) solve this by > having the debugger let you step through expression evaluation, > without editing the code. Good tools are a wonderful thing, and I think pdb should be enhanced that way (by somebody who has the

Re: [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!

On Wed, Apr 25, 2018 at 4:55 PM, Nathaniel Smith wrote: > On Tue, Apr 24, 2018 at 8:31 AM, Chris Angelico wrote: >> The most notable change since last posting is that the assignment >> target is no longer as flexible as with the statement form of >> assignment,

Re: [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!

On Tue, Apr 24, 2018 at 8:31 AM, Chris Angelico wrote: > The most notable change since last posting is that the assignment > target is no longer as flexible as with the statement form of > assignment, but is restricted to a simple name. > > Note that the reference implementation

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

On 4/24/2018 8:56 PM, Tim Peters wrote: The alternative is typing the sub-expression(s) of interest by hand at the debugger prompt, or adding print()s, both of which are prone to introducing typos, or changing results radically due to triggering side effects in the code invoked by the

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

On 4/24/2018 6:10 PM, Tim Peters wrote: Luckily, I only have to write code for me now, so am free to pick the perfect compromise in every case;-) QOTD !  I'm in the same situation. ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

On Wed, Apr 25, 2018 at 4:56 AM, Tim Peters wrote: > [Tim] > >> Binding expressions are debugger-friendly in that they _don't_ just > >> vanish without a trace. It's their purpose to _capture_ the values of > >> the expressions they name. Indeed, you may want to add them

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

On Wed, Apr 25, 2018 at 6:15 AM, Nick Coghlan wrote: > On 25 April 2018 at 13:56, Guido van Rossum wrote: > > On Tue, Apr 24, 2018 at 8:24 PM, Nick Coghlan > wrote: > >> > >> I also think it would be good for the PEP to spell out the

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

On Wed, Apr 25, 2018 at 6:16 AM, Steven D'Aprano wrote: > On Tue, Apr 24, 2018 at 03:54:30PM -0700, Guido van Rossum wrote: > > > We should really take this back to python-ideas at this point. > > Please no :-( > ​+1 ​ ___

Re: [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!

On Tue, Apr 24, 2018 at 11:55:16PM -0700, Nathaniel Smith wrote: > These examples all make me very nervous. The order of execution in > comprehensions is pretty confusing to start with (right to left, > except when it's left to right!). I don't think comprehensions are ever right to left. With

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

On Wed, Apr 25, 2018 at 2:27 AM, Steve Holden wrote: > On Wed, Apr 25, 2018 at 6:16 AM, Steven D'Aprano > wrote: > >> On Tue, Apr 24, 2018 at 03:54:30PM -0700, Guido van Rossum wrote: >> >> > We should really take this back to python-ideas at this

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

On Apr 24, 2018, at 2:10 PM, MRAB wrote: > > On 2018-04-21 03:15, Tim Peters wrote: >> [Tim] >> >> And I'll take this opportunity to repeat the key point for me: I >> >> tried hard, but never found a single case based on staring at real >> >> code where allowing

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

On Thu, Apr 26, 2018 at 1:46 AM, Guido van Rossum wrote: > On Wed, Apr 25, 2018 at 2:27 AM, Steve Holden wrote: >> >> On Wed, Apr 25, 2018 at 6:16 AM, Steven D'Aprano >> wrote: >>> >>> On Tue, Apr 24, 2018 at 03:54:30PM -0700, Guido

[Python-Dev] Meta-question about this mailing list

Hi, the description on https://mail.python.org/mailman/listinfo/python-dev reads: "On this list the key Python developers discuss the future of the language and its implementation." I interpret this sentence as "only key (core?) developers are supposed to participate in the discussion (ie.

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Thu, Apr 26, 2018 at 6:21 AM, Łukasz Langa wrote: > := also goes against having one obvious way to do it. Since it's an > expression, > it can also be placed on its own line or in otherwise weird places like > function call arguments. I anticipate PEP 8 would have to be

Re: [Python-Dev] PEP 573 -- Module State Access from C Extension Methods

On 04/24/18 13:12, Jeroen Demeyer wrote: On 2018-04-24 16:34, Jeroen Demeyer wrote: On the other hand, if you are passing the function object, then you can get __self__ from it (unless it's an unbound method: in that case __self__ is NULL and self is really args[0]). So there wouldn't be a need

Re: [Python-Dev] PEP 573 -- Module State Access from C Extension Methods

On 04/25/18 14:46, Jeroen Demeyer wrote: On 2018-04-25 20:33, Petr Viktorin wrote: Perhaps "m_objclass" could point to the module in this case That was exactly my idea also today. Instead of treating m_objclass as the defining class, we should generalize it to be the "parent" of the

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

> On 25 Apr, 2018, at 1:24 PM, Chris Angelico wrote: > > On Thu, Apr 26, 2018 at 6:21 AM, Łukasz Langa wrote: >> := also goes against having one obvious way to do it. Since it's an >> expression, >> it can also be placed on its own line or in otherwise weird

Re: [Python-Dev] PEP 573 -- Module State Access from C Extension Methods

On 2018-04-25 20:33, Petr Viktorin wrote: Perhaps "m_objclass" could point to the module in this case That was exactly my idea also today. Instead of treating m_objclass as the defining class, we should generalize it to be the "parent" of the function: either the class or the module.

[Python-Dev] PEP 394 update proposal: Allow changing the `python` command in some cases

Hello, In Fedora, I found that PEP 394's strict recommendation that `python` points to `python2` is holding us back. From discussions on Zulip and elsewhere it's clear that this recommendation is not changing any time soon, but I would like to officially relax it in several cases. The

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

A very emotional appeal, you don't seem to grasp the usability improvements this will give. I hear you but at this point appeals to Python's "Zen" don't help you. On Wed, Apr 25, 2018 at 1:21 PM, Łukasz Langa wrote: > PEP 572 caused a strong emotional reaction in me. I wanted

[Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

PEP 572 caused a strong emotional reaction in me. I wanted to first understand my intuitive objection to the idea before posting anything. I feel that (name := expression) doesn't fit the narrative of PEP 20. It doesn't remove complexity, it only moves it. What was its own assignment before now

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

> On 25 Apr, 2018, at 1:28 PM, Guido van Rossum wrote: > > You don't seem to grasp the usability improvements this will give. I hear you > but at this point appeals to Python's "Zen" don't help you. This reads dismissive to me. I did read the PEP and followed the discussion

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

On Wed, Apr 25, 2018 at 2:17 PM, Terry Reedy wrote: > On 4/25/2018 6:10 AM, Steve Holden wrote: >> Indeed, in the cases where I currently find myself unwrapping expressions >> to capture their values in local variables for debugging purposes it would >> usually be far less

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Guido] >> You don't seem to grasp the usability improvements this will give. >> I hear you but at this point appeals to Python's "Zen" don't help you. [Łukasz Langa ] > This reads dismissive to me. I did read the PEP and followed the discussion on > python-dev. I referred to PEP

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Tim] >> To my eyes, this is genuinely harder to follow, despite its relative brevity: >> >> while total != (total := total + term): [Antoine] > Does it even work? Perhaps if the goal is to stop when total is NaN, > but otherwise? I don't follow you. You snipped all the text explaining

Re: [Python-Dev] Visual similarity of "=" and "==" (in context of PEP 572)

On Thu, Apr 26, 2018 at 9:54 AM, Mikhail V wrote: > Since the discussion about operator choice has completely migrated > here, I'll put my note also here. > From the very beginning of PEP 572 discussion I have noticed > a strange fact - there is told a lot about visual

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Wed, Apr 25, 2018 at 8:22 PM Chris Angelico wrote: [..] > > my_func(arg, buffer=(buf := [None]*get_size()), size=len(buf)) > > > > To my eye this is an anti-pattern. One line of code was saved, but the > > other line becomes less readable. The fact that 'buf' can

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Thu, 26 Apr 2018 08:38:51 +1000 Chris Angelico wrote: > On Thu, Apr 26, 2018 at 8:08 AM, Antoine Pitrou wrote: > > On Wed, 25 Apr 2018 16:55:43 -0500 > > Tim Peters wrote: > >> > >> To my eyes, this is genuinely harder to

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Thu, 26 Apr 2018 10:20:40 +1000 Chris Angelico wrote: > On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov > wrote: > > Just yesterday this snippet was used on python-dev to show how great the > > new syntax is: > > > > my_func(arg,

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

On 4/25/2018 6:10 AM, Steve Holden wrote: On Wed, Apr 25, 2018 at 4:56 AM, Tim Peters > wrote: [Tim] >> Binding expressions are debugger-friendly in that they _don't_ just >> vanish without a trace.  It's their purpose to _capture_

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Thu, Apr 26, 2018 at 8:08 AM, Antoine Pitrou wrote: > On Wed, 25 Apr 2018 16:55:43 -0500 > Tim Peters wrote: >> >> To my eyes, this is genuinely harder to follow, despite its relative brevity: >> >> while total != (total := total + term): > >

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

[Tim] To my eyes, this is genuinely harder to follow, despite its relative brevity: while total != (total := total + term): [Antoine] >>> Does it even work? Perhaps if the goal is to stop when total is NaN, >>> but otherwise? [Chris] >> Yes, it does, because the

[Python-Dev] Visual similarity of "=" and "==" (in context of PEP 572)

Since the discussion about operator choice has completely migrated here, I'll put my note also here. >From the very beginning of PEP 572 discussion I have noticed a strange fact - there is told a lot about visual similarity of "=" and "==" in Python. *Same is told in the PEP 572 (frequently asked

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Wed, 25 Apr 2018 18:55:56 -0500 Tim Peters wrote: > > > the shorthand version appears completely bonkers. > > I wouldn't go that far, but I already said I wouldn't write it that way. > > However, without looking at real code, people are just flat-out > guessing about

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Wed, Apr 25, 2018 at 1:55 PM, Łukasz Langa wrote: > > > On 25 Apr, 2018, at 1:28 PM, Guido van Rossum wrote: > > > > You don't seem to grasp the usability improvements this will give. I > hear you but at this point appeals to Python's "Zen" don't help you.

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On 04/25/2018 03:15 PM, Ethan Furman wrote: On 04/25/2018 02:55 PM, Tim Peters wrote: This becomes a question of seasoned judgment. For example, here's a real loop summing a series expansion, until the new terms become so small they make no difference to the running total (a common enough

Re: [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!

> # Handle a matched regex > if (match := pattern.search(data)) is not None: > ... > > # A more explicit alternative to the 2-arg form of iter() invocation > while (value := read_next_item()) is not None: > ... > > # Share a subexpression between a comprehension

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Wed, 25 Apr 2018 16:55:43 -0500 Tim Peters wrote: > > To my eyes, this is genuinely harder to follow, despite its relative brevity: > > while total != (total := total + term): Does it even work? Perhaps if the goal is to stop when total is NaN, but otherwise?

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Wed, Apr 25, 2018 at 01:55:37PM -0700, Łukasz Langa wrote: > > > On 25 Apr, 2018, at 1:28 PM, Guido van Rossum wrote: > > > > You don't seem to grasp the usability improvements this will give. I hear > > you but at this point appeals to Python's "Zen" don't help you. > >

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On 04/25/2018 02:55 PM, Tim Peters wrote: This becomes a question of seasoned judgment. For example, here's a real loop summing a series expansion, until the new terms become so small they make no difference to the running total (a common enough pattern in code slinging floats or decimals):

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Wed, Apr 25, 2018 at 3:15 PM, Ethan Furman wrote: > On 04/25/2018 02:55 PM, Tim Peters wrote: > >> To my eyes, this is genuinely harder to follow, despite its relative >> brevity: >> >> while total != (total := total + term): >> term *= mx2 /

Re: [Python-Dev] The new and improved PEP 572, same great taste with 75% less complexity!

On Thu, Apr 26, 2018 at 9:05 AM, Victor Stinner wrote: >> # Handle a matched regex >> if (match := pattern.search(data)) is not None: >> ... >> >> # A more explicit alternative to the 2-arg form of iter() invocation >> while (value := read_next_item())

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Wed, Apr 25, 2018 at 5:58 PM Guido van Rossum wrote: [..] > It was meant dismissive. With Chris, I am tired of every core dev starting their own thread about how PEP 572 threatens readability or doesn't reach the bar for new syntax (etc.). These arguments are entirely

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov wrote: > Just yesterday this snippet was used on python-dev to show how great the > new syntax is: > > my_func(arg, buffer=(buf := [None]*get_size()), size=len(buf)) > > To my eye this is an anti-pattern. One