[Python-Dev] SyntaxError: can't assign to function call (original) (raw)

Guido van Rossum guido at python.org
Thu Aug 10 21:28:08 CEST 2006

On 8/10/06, James Y Knight <foom at fuhm.net> wrote:

On Aug 10, 2006, at 12:24 PM, Guido van Rossum wrote: > On 8/10/06, James Y Knight <foom at fuhm.net> 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/)

More information about the Python-Dev mailing list