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

[Chris Angelico]

On Thu, Apr 26, 2018 at 6:30 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> On Thu, 26 Apr 2018 17:29:17 +1000
> Steven D'Aprano <steve at pearwood.info> wrote:
>> On Thu, Apr 26, 2018 at 07:16:28PM +1200, Greg Ewing wrote:
>> > Tim Peters wrote:
>> > >As a statement in a program (as opposed to typed at a shell),
>> > >"a := 3" has the unnecessary (in that context) property of returning
>> > >(and discarding 3), so it's better style to use "a = 3" in that
>> > >context.
>> >
>> > That seems like a post-hoc justification. If := were the one
>> > and only assignment symbol, the compiler could easily optimise
>> > away the extra DUP_TOP or whatever is involved.
>>
>> Its still bad form to rely on compiler-dependent optimizations which
>> aren't part of the language specification.
>
> If such were the need, you could very well make it part of the language
> specification.  We are talking about a trivial optimization that any
> runtime could easily implement (e.g. if a sequence `DUP_TOP, STORE_FAST,
> POP_TOP` occurs, replace it with `STORE_FAST`).

Not at the REPL, no. At the REPL, you need to actually print out that
value. It's semantically different.

> Any runtime already has to implement a set of performance properties
> that's far less trivial than that.  For example, any decent runtime is
> expected to provide amortized O(1) list append or dict insertion.  You
> are breaking user expectations if you don't.

You assume that, but it isn't always the case. Did you know, for
instance, that string subscripting (an O(1) operation in CPython) is
allowed to be O(n) in other Python implementations?

Now you do.

ChrisA