[Python-Dev] PEP 203 Augmented Assignment

[Michael Hudson]

Thomas Wouters <thomas@xs4all.net> writes:

[opcodes for augmented assignment]
> I now realize only 11 new opcodes are necessary, and it can even be reduced
> to 1, by splitting the operation into seperate LOAD, <operation>, and STORE
> instructions, with a few ROT_TWO and ROT_THREE's mixed in. <operation> could
> be a new bytecode for each operation (11 in total) or a single 'AUGOP'
> bytecode with an argument to specify the operation.

Can you really do

a[b:c] += d

with ROT_THREE & ROT_TWO?  I thought one couldn't when I was doing the
first patch, but maybe I'm wrong.

> I think it's less elegant from the bytecode point of view, but it does
> require a lot less changes in ceval/compile. There is only one significant
> difference between the current version and this, and that's behaviour in the
> face of threads.

And size of bytecode!

> I had originally seen augmented assignment as a way to increment a counter
> 'thread-safe': the load and store operation are done in one bytecode, and
> can thus not be interrupted by a thread switch. But after thinking about it,
> it doesn't make that much sense. It only works for builtin types, not for
> classes defining a __op_ab__, and possibly not for extention types. In fact,
> there might be some possibility for a thread switch even in builtin types,
> though I have never looked at that.
> 
> Opinions ? Is the semi-reliability in the face of threads a good idea ? 

IMHO, yes.

> Did I miss anything important about the current implementation ?
> Should I forget about this idea and keep the patch as it is (and go
> back to my PEP) or should I rewrite the patch and then rewrite the
> PEP ?

For now, I'd just write the PEP.

Cheers,
M.

-- 
  On the other hand,  the following areas are subject to boycott
  in reaction to the rampant impurity of design or execution, as
  determined after a period of study, in no particular order: 
    ...                              http://www.naggum.no/profile.html