On May 2, 9:46 pm, Stargaming <[EMAIL PROTECTED]> wrote:
> > del tmp2
> > y = tmp3 # tmp3 gets evaluated as assignment is overloaded
>
> To allow lazy evaluation, you need overloading of the assignment
> operator?
No I don't. I could for example delay evaluation until some data from
y is requested, say when
x = y[5]
is executed. However, that can allow mutual dependencies between
unevaluated expressions. These can be complicated to resolve, and is
an issue similar to to that of cyclic dependencies in reference
counting. With an overloaded assignment operator, we would avoid this
as assignments are natural places to flush lazy evaluations. No
dangling unevaluated expression would be produced, and thus there
would be no strange bugs of this sort.
> Where should you overload it? y is less than None when you do
> that assignment.
In this case, I am not suggesting overloading
y =
but rather overloading
= tmp3
That is, when a variable is bound to an object, a method is called
(e.g. __get__) and the variable gets the return value output from that
function instead. It is analogous to the __get__ method of
descriptors. COnsider happens when we call
a = someObject.someProperty
and someProperty has a __get__ method. Even if a is less than None, we
still get a call to __get__.
On the other hand, if y had been bound to a value before hand, it
would be meaningful to call a method called __set__ on y when
y = tmp3
is executed. Just like
someObject.someProperty = value
would call __set__ on someProperty if it had one. Obviously if
someObject.someProperty had been unbound, there would have been no
call to __set__.
So I am suggesting generalising __set__ and __get__ to overload the
assignment operator.
This would be an example:
class Foo(object):
def __init__(self):
self.value = None
def __set__(self,value):
''' overloads bar = value after bar = Foo()'''
self.value = value
def __get__(self):
''' overloads obj = bar after bar = Foo()'''
return self.value
So it is just a generalization of the already existing descriptors. It
even makes descriptors and properties easier to understand.
> I don't really see the need for overloading here.
> Following the binding rules, __mul__ would (even without any hackery) be
> evaluated before __add__.
Yes, but at the cost of generating several temporary arrays and
looping over the same memory several times. If the assignment operator
could be overloaded, we could avoid the temporary objects and only
have one loop. For numerical code, this can mean speed ups in the
order of several magnitudes.
Sturla Molden
>
>
> > Should there be a PEP to overload the assignment operator?
>
> If -- after this discussion -- community seems to like this feature, you
> could try to come up with some patch and a PEP. But not yet.
>
> > In terms of
> > syntax, it would not be any worse than the current descriptor objects
> > - but it would make lazy evaluation idioms a lot easier to implement.
>
> --
> Stargaming
--
http://mail.python.org/mailman/listinfo/python-list
