[Python-Dev] Augmented assignment

[M.-A. Lemburg]

Thomas Wouters wrote:
> 
> I'd like some (minor) feedback on the augmented assignment thing I'm working
> on. I understand Guido is the only one who accepts patches like this, and
> appreciate that, but I'm hoping someone can at least tell me what I'm doing
> wrong so I can fix it before Guido sees it ;-) But if I'm being an impatient
> flap, just tell me so and I'll calm down.

I'd make this a 1.7 issue. 1.6 should go into the stabilization
phase and big complicated patches like yours should receive some
more design and concept discussion before getting checked in.

BTW, with "augmented assign" I suppose you mean things like
a += 1 and b *= 2, right ?

> I also appreciate the fact that the patch is quite large, and not many
> people have the time to scrutinize each version, so I'll summerize the
> issues I'm uncertain about.
> 
>  * The patch needs to add a new type of opcode, one that takes 2 arguments.
> This is because the opcodes that load, change and store a name need one
> argument for the index in the name table (or local variable number), and one
> argument for the actual operation.
> 
> It could also work by using PyInt or another PyObject to pass the extra
> argument on the stack, but I don't think pushing a non-PyObject-pointer onto
> the stack is a good idea. Adding 2-argument opcodes seemed the easiest
> solution.
> 
> However, I'm not really into Python-hacking (or was, I should say, because
> it's great fun) and the python-dev list doesn't seem to be searchable ;) so
> I can't know if this issue has come up before. Has it ? Would the new
> opcode-type be an unsurpassable problem ? should I use the stack instead ?

Any reason you can't do this with the existing op codes ?

E.g. a += b

1. load a
2. load b
3. add
4. store a

> * The patch also needs to add 11 new __hooks__, 11 new API calls, 11 new entries
> in the PyNumberMethods struct and 2 new entries in the PySequenceMethods
> struct. Would that conceivably be a problem ? I've heard people on the
> python-list complain about this ;-P

More generic solutions are usually more accepted.

BTW, before hacking too much into this, you ought to consider
that we are planning for rich comparisons and decentralized
coercion in 1.7 (this was planned for 1.6, but David and I
got carried away with other things).
 
I wouldn't want to have to hack 11 new slots to get this right...

>  * Should I start sending the patch, in pieces, to the patches-list, or is
> it a wasted effort because noone will touch it until Guido is back ? If I
> should send it, should I send it in one large patch (minus autogenerated
> files) or in nice functionality-sized pieces ?

Better put it on a web page and inform python-dev of new features,
enhancements, etc.
 
>  * How 'cool' does Guido actually think this syntax is ? Apparently the
> subject has come up a few times ;) and I got positive signals from both Tim
> and Guido, but if the patch won't go in as a patch, and won't actually be
> used other than some inspiration for a future rewrite of the CPython core,
> I'm not going to worry too much about the patch ;)

Having a patch is good for discussion, whether it gets incorporated
is a different issue ;-)
 
-- 
Marc-Andre Lemburg
______________________________________________________________________
Business:                                      http://www.lemburg.com/
Python Pages:                           http://www.lemburg.com/python/