Gabriel Genellina <[EMAIL PROTECTED]> 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] -- http://mail.python.org/mailman/listinfo/python-list
