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

[Larry Hastings ] >>> I hate to be pedantic--there's enough of that going on in this thread--but I >>> can't agree with the word "simplifed" above. I agree that the code using >>> binding expressions is shorter. But considering that emit the two code >>> examples implement the exact same algorith

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

On Thu, Apr 26, 2018 at 4:27 PM, Kirill Balunov wrote: > > > 2018-04-24 18:31 GMT+03:00 Chris Angelico : >> >> >> > > Not sure, but if additional motivating examples are required, there is a > common pattern for dynamic attribute lookup (snippet from `copy.py`): > > reductor = dispatch_table.g

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

On 04/26/2018 12:12 PM, Tim Peters wrote: [Larry Hastings ] I hate to be pedantic--there's enough of that going on in this thread--but I can't agree with the word "simplifed" above. I agree that the code using binding expressions is shorter. But considering that emit the two code examples im

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

[Kirill Balunov] > Not sure, but if additional motivating examples are required, there is a > common pattern for dynamic attribute lookup (snippet from `copy.py`): > > reductor = dispatch_table.get(cls) > if reductor: > rv = reductor(x) > else: > reductor = getattr(x, "_

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

On 04/26/2018 11:18 AM, Chris Angelico wrote: In the reference implementation, it's just DUP_TOP followed by STORE_FAST (well, technically by "whatever the assignment compiles to", as it could be affected by global/nonlocal, closures, etc). Is there much advantage to creating a new opcode? Pr

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

With the new name restriction on the LHS, I'm now -0 on this. While I don't think the benefits outweigh the overhead cost of pushing Python closer to not fitting in my brain, I would admittedly use this if provided to me. (I also put this in the bucket of consenting adult features; ripe for abuse,

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

On Fri, Apr 27, 2018 at 4:07 AM, Larry Hastings wrote: > * I assume that--if we don't already have one--we'll add a new > DUP_AND_STORE_FAST opcode for binding expressions. On the other hand, > "STORE_FAST n" followed by "LOAD_FAST n" is a common enough bytecode idiom > that the peephole optimize

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

On 04/26/2018 06:27 AM, Kirill Balunov wrote: Not sure, but if additional motivating examples are required, there is a common pattern for dynamic attribute lookup (snippet from `copy.py`):     reductor = dispatch_table.get(cls)     if reductor:     rv = reductor(x)     else:     reduc

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

[Kirill Balunov ] > Not sure, but if additional motivating examples are required, there is a > common pattern for dynamic attribute lookup (snippet from `copy.py`): > > reductor = dispatch_table.get(cls) > if reductor: > rv = reductor(x) > else: > reductor = getattr(x, "

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

2018-04-24 18:31 GMT+03:00 Chris Angelico : > > Recommended use-cases > = > > [...] > > # Capturing regular expression match objects > # See, for instance, Lib/pydoc.py, which uses a multiline spelling > # of this effect > if match := re.search(pat, text): >

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

[Guido] > Maybe the order for d[k] = v should also be reconsidered? There's certainly code in the wild relying on the order "v, then d, then k", because that's just how assignment statements have always worked (dicts or not). I'd rather change the dict comprehension code, because I think the anal

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

FWIW There's an existing issue (bpo 29652 ) for the order of evaluation in dict-comps. Best Regards, Jim Fasarakis Hilliard On Thu, Apr 26, 2018 at 7:06 PM, Chris Angelico wrote: > On Fri, Apr 27, 2018 at 2:02 AM, Guido van Rossum > wrote: > > Maybe the o

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

On Fri, Apr 27, 2018 at 2:02 AM, Guido van Rossum wrote: > Maybe the order for d[k] = v should also be reconsidered? If so, it would be something like: 1) Evaluate d 2) Evaluate k 3) Evaluate v 4) Call d.__setitem__(k, v), via slots etc In a vacuum, I don't have a problem with that. But I suspe

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

Maybe the order for d[k] = v should also be reconsidered? On Thu, Apr 26, 2018, 08:23 Chris Angelico wrote: > On Fri, Apr 27, 2018 at 1:07 AM, Guido van Rossum > wrote: > > Just as I feared. While currently fixing this is just fixing a bug > (nobody's > > code is going to break except perhaps s

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

On Fri, Apr 27, 2018 at 1:07 AM, Guido van Rossum wrote: > Just as I feared. While currently fixing this is just fixing a bug (nobody's > code is going to break except perhaps some tests), with PEP 572 fixing this > would be mandatory. > > On Thu, Apr 26, 2018 at 6:57 AM, Nick Coghlan wrote: >> >

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

Just as I feared. While currently fixing this is just fixing a bug (nobody's code is going to break except perhaps some tests), with PEP 572 fixing this would be mandatory. On Thu, Apr 26, 2018 at 6:57 AM, Nick Coghlan wrote: > On 25 April 2018 at 18:23, Chris Angelico wrote: > x={print(2)

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

On 25 April 2018 at 18:23, Chris Angelico wrote: x={print(2): print(1) for _ in [1]} > 1 > 2 > > Hm. One of these is not like the others... Huh, it looks like we missed checking dict comprehensions when we fixed dict displays to evaluate keys before the corresponding values. That wou

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()) is not None: >>

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] 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 on

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, but is restricted to a simple name.

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 has not been updat

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

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 has not been updated. ChrisA PEP: 572 Title: Assignment Expressions Author: Chri