Python Success stories

[Mark Wooding]

Gabriel Genellina <gagsl-py2 at yahoo.com.ar> wrote:

> Because Python doesn't follow the "boxed variables" model. 

Be careful here.  `Boxed types' or `boxed objects' is a technical term
essentially meaning `heap-allocated objects, probably with reference
semantics', which Python most definitely does use -- so this almost
means the opposite of what you're talking about.

Python has the same basic data model as Lisp, Ruby, Smalltalk and many
other languages: a variable (or a `slot' in a compound data-object)
contains a reference to value; values can referred to by many variables.
Assignment simply copies these references around.  This means that it's
easy to end up sharing the same object between lots of variables (or
structures).

Contrast this to the model used by C, Pascal and other `traditional'
compiled languages, where a variable is actually a container for a
value, and assignment is a copying operation rather than a sharing
operation.

> In other languages i++ changes the "value" stored inside the box "i",
> but the box itself (the variable) is still the same. Python doesn't
> have boxes, it has names that refer to objects. For all builtin
> numeric types, i += 1 creates a *new* object with the resulting value
> and makes the name "i" refer to this new object.

Note that `+=' in Python is inconsistent!  For numeric types (and other
immutable types, such as strings or tuples), `VAR += VALUE' means the
same thing as `VAR = VAR + VALUE' (ignoring tedious issues of multiple
evaluation of subexpressions -- e.g., subscripts -- in VAR), which as
mentioned above causes a new reference to be stored in VAR, referring to
the object which was computed by adding VALUE to the object previously
referred to by VAR.  For lists, it does not do this: instead, it extends
the list in place, putting new values on the end of it.

(This is one of the language's few obvious inconsistencies, and probably
a reasonably justifiable one; but it's still worth pointing out.)

To be honest, I don't see any particular reason why `++' is any more of
a mutation operation than `+=' is in the languages that define it;
Python is actually one of the few to define one but not the other.  (The
other one I can think of is Acorn's BBC BASIC, for whatever that's
worth; it too lacks `++'.)  But then again, one of the main conceptual
advantages of `++' as an operator is that it has both pre- and post-
increment variants, which are useful when used as part of a wider
expression.  This won't hold in Python, since assignments (which `++'
assuredly ought to be) aren't allowed as subexpressions anyway.  So the
value of `++' would be limited to providing an abbreviation over the
already quite short `+= 1'.

That's not quite true, in fact: it might be useful to define other kinds
of incrementing for specialist types, but I can't think of any obvious
examples off the top of my head.

This argument doesn't apply to `+=' which has the benefit of saving you
from having to type the VAR twice (which is nontrivial if VAR contains
complex subexpressions) and -- more significantly -- saves a reader from
having to check whether VAR and VAR' actually match in `VAR = VAR' +
VALUE' and ensures only single evaluation of subexpressions of VAR.
None of this applies to `++'.  So `++' is not a feature I find myself
sorely missing in Python.

-- [mdw]