Home Original page

[Python-ideas] New __reference__ hook

Terry Reedy tjreedy at udel.edu
Wed Dec 5 22:59:15 CET 2012 
On 12/5/2012 1:09 PM, Sturla Molden wrote:
> On 05.12.2012 18:05, Jasper St. Pierre wrote:
>> And? What's wrong with an __iadd__ that's exactly the same as Mike's
>> __add__?
>
> I think it was a Java-confusion. He thought numbers were copied on
> assignment. But there is no difference between value types and object
> types in Python. Ints and floats are immutable, but they are not value
> types as in Java.
>
> But apart from that, I think allowing overloading of the binding
> operator "=" might be a good idea.

An assignment statement mutates the current local namespace. The 
'current local namespace' is a hidden input to the function performed by 
all statements, but it need not be a python object. The key symbol '=' 
is not an operator and 'a = b' is not an expression.

> A special method __bind__ could
> return the object to be bound:
>
>     a = b
>
> should then bind the name "a" to the return value of
>
>     b.__bind__()

If one wants to perform 'a = f(b)' or 'a = b.meth()' instead of 'a = b', 
then one should just explicitly say so.

> if b implements __bind__.
>
> Sure, it could be used to implement copy on assignment. But it would
> also do other things like allowing lazy evaluation of an expression.
>
> NumPy code like
>
>     z = a*x + b*y + c
>
> could avoid creating three temporary arrays if there was a __bind__
> function called on "=".

No, z = (a*x + b*y * c).__bind__, which is how you defined .__bind__ 
working, still requires that the expression be evaluated to an object.

The definition of Python requires computation of a*x, b*y, (a*x + b*y), 
and finally (a*x + b*y) + c in that order. Either '*' or '+' may have 
side-effects.

> This is a big thing, cf. the difference between
> NumPy and numexpr:
>
>     z = numexpr.evaluate("""a*x + b*y + c""")

> The reason numerical expressions must be written as strings to be
> efficient in Python is because there is no __bind__ function.

No, it is because the semantics of Python require inefficiency that can 
only be removed by a special parser-compiler with additional knowledge 
of the relevant object class, method, and instance properties. Such 
knowledge allows code to be re-written without changing the effect. For 
Fortran arrays, the needed information includes the number and length of 
each dimension. These are either declared or parameterized and passed as 
arguments.

https://code.google.com/p/numexpr/wiki/Overview
says that numexpr.evaluate(ex) first calls compile(ex), but does not say 
whether it has compile compile to cpython bytecode or only to ast. In 
either case, it converts arraywise operations to blockwise operations 
inside loops run on a custom C-coded virtual machine. They imply that 
this is not as good as elementwise operations compiled to native machine 
code. In any case, it knows that numpy array operations are side-effect 
free and must use the runtime dimension and size info.

-- 
Terry Jan Reedy
More information about the Python-ideas mailing list