This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author serhiy.storchaka
Recipients benjamin.peterson, brett.cannon, josh.r, ncoghlan, rhettinger, scoder, serhiy.storchaka, steven.daprano
Date 2019-11-16.17:20:05
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1573924806.28.0.468425233193.issue32856@roundup.psfhosted.org>
In-reply-to
Content
> However, that's still going to be clearer to most readers than writing

It is subjective. To me, j+1/j looks clearer than (j:=i*i)+1/j. In addition, the for-as-assignment idiom is more powerful in context of comprehensions, it allows to set an initial value. In any case I want to have a choice.

> OOC, rather than optimizing a fairly ugly use case, might another approach be to make walrus less leaky?

I think this ship is sailed. The semantic of the walrus operator is complex enough to make it even more complex by adding more special cases. Also, while the function-wide optimization of variables is possible, it much more complex problem than the proposed simple optimization.

> You should probably rerun your benchmarks though

$ ./python -m timeit -s 'a = list(range(1000))' -- '[y for x in a for y in [x]]'
Unpatched:  5000 loops, best of 5: 66.8 usec per loop
Patched:   10000 loops, best of 5: 21.5 usec per loop

$ ./python -m timeit -s 'a = list(range(1000))' -- '[x for x in a]'
20000 loops, best of 5: 17.8 usec per loop

Issue32925 reduce the difference, but it is still large (~12).
History
Date User Action Args
2019-11-16 17:20:06serhiy.storchakasetrecipients: + serhiy.storchaka, brett.cannon, rhettinger, ncoghlan, scoder, benjamin.peterson, steven.daprano, josh.r
2019-11-16 17:20:06serhiy.storchakasetmessageid: <1573924806.28.0.468425233193.issue32856@roundup.psfhosted.org>
2019-11-16 17:20:06serhiy.storchakalinkissue32856 messages
2019-11-16 17:20:05serhiy.storchakacreate