A Summary: Expression-Assignments. (Very Long)

Michael P. Reilly arcege at shore.net
Fri May 14 10:40:38 EDT 1999


Phil Hunt <philh at vision25.demon.co.uk> wrote:
: In article <3739D550.6845EAFD at appliedbiometrics.com>
:            tismer at appliedbiometrics.com "Christian Tismer" writes:
:> Anyway it is great as it is, please don't ever change it,
:> and no assignment expressions, no +=, all crap.

: I'd like to see += in Python.

Since assignment works on references to variables, this can lead to some
complications.  Also, there are a good number of ambiguities that result
from working with overloaded objects.

There was a whole thread on this that is probably still on dejanews
(don't have a reference point for that tho).  But one example of this
ambiguity is:

  x = 1    # simple assignment
  x += 2   # simple: x = ( x + 2 )
  x += B() # should x now result in an integer or an instance of B?

Is it safe to make some assumptions?  Granted, this is a simple
example, and the assumption is probably clear (hey, I've only had one
cup of coffee, my examples can't get too complex yet ;).  But there are
plenty of other situations where the semantics wouldn't be clear from
the statement.

More importantly, how many times does "x" get evaluated in such a
statement?  And with some objects that can become important (database
objects, etc.).  Is += implimented as a new syntax to evaluate to "x =
x + y" or as a new special method like __add__, or as a combination?

Usually it is better to be clear and more verbose (the age old wisdom
of "When in doubt, parenthesize").  This is a basic tenet of Python
(correct me if I'm getting off the mark, Guido :).

I'm not suggesting we revisit the debate (I saw enough of that debate,
thank you ;), just explaining to someone who asked.

  -Arcege





More information about the Python-list mailing list