Why not an __assign__ method?

[Robin Thomas]

At 01:26 PM 3/30/01 -0300, Carlos Alberto Reis Ribeiro wrote:

>The question is: Why not have a __assign__ method, that gets called on 
>assignment? It should be called on the *right side* of the expression (at 
>the left side it does not make sense - I leave the proof as an exercise 
>for the reader <wink>). The return value would be then assigned to the 
>left side of the expression.

You should really get the source to CPython and start reading it.

>z = a + b + c

The "no changes to Python" implementation of your example is:

z = a + b
z += c

Think about operations, not methods.


>Then the expression is broken in steps like this (not exact syntax, but 
>enough to give you the idea):
>
>i1 = a.__add__(b)
>i2 = i1.__add__(c)
>return i2

Read the source code. File Python/ceval.c, grep for "ADD". Thrill at the 
majestic expanse of the switch statement on Python opcode values.

The "exact syntax" (sic) of the addition operation is different than above, 
and different in a way that undermines the idea of "method calls" that you 
are illustrating in order to support a new __assign__ method.

>There are two instantiations of temporary arrays, where only one would be 
>enough. With big arrays the extra temp copy is quite an issue. I intend to 
>do some image manipulatin, and that surely will help a lot.
>
>The mechanism that I have in mind is:

...something that has nothing to do with your proposed __assign__ method.

>1) Set a "temp" flag for objects created in the middle of an expression...

...objects that support the in-place version of the regular numeric 
operator represented by the opcode occurring a few bytes forward in the 
bytecode stream? Think about what "middle of an expression" means.

>2) If a binary operation is called upon a temporary object, use it to 
>store the result (of course, if the semantics allows).

See above.

>3) Reset "temp" on assign.

Think about what your "temp flag" would do under the current behavior of 
threads in Python.

Think about how you want to turn this:

z = a + b + c

into the syntax-illegal but perhaps (and perhaps not) bytecode-legal:

z = ((a + b) += c)

I say "perhaps not" because I'm not going to look at the source to 
determine whether this is feasible. You do it. You will discover why a + b 
+= c is not allowed, and whether that can and should be changed.

Think about why you consider these intermediate objects as "temporary", 
whether Python currently treats them as "temporary", and if so, how they 
are discarded.

Use the dis module for the standard library. Look at the bytecode for:

a + b + c # expression

versus

z = a + b + c # statement

versus

z = a + b
z += c  # two statements

versus

z = a + b + c % (d * e) / f ^ (g or 42)

I hope this will keep you busy for a while! :)


--
robin900 at yahoo.com


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com