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