[Python-Dev] SyntaxError: can't assign to function call

[Guido van Rossum]

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/)