On 8/10/06, James Y Knight <[EMAIL PROTECTED]> wrote:
> On Aug 10, 2006, at 12:24 PM, Guido van Rossum wrote:
> > On 8/10/06, James Y Knight <[EMAIL PROTECTED]> wrote:
> >> It makes just as much sense as assigning to an array access, and the
> >> semantics would be pretty similar.
> >
> > No. Array references (x[i]) and attribute references (x.a) represent
> > "locations". Function calls represent values. This is no different
> > than the distinction between lvalues and rvalues in C.
>
> Yes, function calls cannot be lvalues right now. However, there is no
> reason that a function call _could not_ be an lvalue. That is exactly
> what the addition of __setcall__ would allow.
I have to admit that I don't find it particularly useful -- I still
don't think I like the idea much of using function calls as assignment
targets.
You wrote
x(5) = True
would mean
x.__setcall__(True, 5)
What would x(5) += 1 mean? The best I can come up with is
__tmp = x(5) # or x.__call__(5)
if hasattr(__tmp, "__iadd__"):
__val = __tmp.__iadd__(1)
else:
__val = __tmp + 1
if __val is NotImplemented:
raise TypeError(...)
__tmp.__setcall__(__val, 5)
since this is essentially how x[5] += 1 works (except that the
hasattr() check is hidden inside PyNumber_InPlaceAdd and optimized
away to class definition time).
I expect that most people interested in having f() += 1 to work would
have to implement a dummy __setcall__() because their __iadd__ returns
self and there's no additional work to be done for the assignment.
I'm not convinced that all this complexity is worth it. For lists, +=
is syntactic sugar for .extend(). I expect that most use cases you can
come up with can similarly be argued away.
> On Aug 10, 2006, at 12:31 PM, Phillip J. Eby wrote:
> > Honestly, it might make more sense to get rid of augmented
> > assignment in Py3K rather than to add this. It seems that the need
> > for something like this springs primarily from the existence of
> > augmented assignment.
I assume this was meant tongue-in-cheek. I see no reason to get rid of
+=. The opportunity for hypergeneralization (== ill-advised
generalization based on the misunderstanding of some mechanism) does
not automatically mean a mechanism should not be added (although it
can sometimes be a warning sign).
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
