[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