Consistency in Python

[Paul Boddie]

Hendrik van Rooyen wrote:
>
> There seems to be no common methods such as-
>     "prepend" - for adding something to the beginning
>     "append" - for adding something to the end
>     "insert[j]" - for adding something somewhere in the middle
>
> Or have I missed something ?

[...]

> BTW - I understand that some things are immutable - but that is an
> implementation detail, not a language issue. - the fact that you get the name S
> bound to a new object is irrelevant to a discussion about how you tell the
> interpreter to do something...

You haven't missed one of the principal reasons exactly, but you
underestimate its importance. There aren't such methods as append or
insert on strings or tuples precisely because those objects are
immutable, whilst such methods on lists and other mutable objects
change the contents of such objects. Moreover, append and insert return
no result because the change occurs within an existing object - if you
were to return a reference to the changed object, it would be the same
reference as the one you already had.

# Append on lists:
l.append(something) # returns nothing (you'll get None)

Now, you could argue that insert and append should always return a
reference to some object, and that for lists (and other mutable
objects) it should return the same reference (to the changed object),
whereas for strings (and other immutable objects) it should return a
different reference (to an object which has the changed contents of the
original object).

# Fictional append on strings:
s2 = s.append(sometext) # s would be the same, s2 different
# Fictional append variant on lists:
l2 = l.append(something) # l and l2 would be the same

However, there's a sort of unwritten guarantee - although it could be
in the documentation - that the append and insert methods specifically
mutate objects and that they therefore have no place in immutable
objects. Certainly, the behaviour illustrated above could be surprising
in some kinds of programs because the append method on strings would be
more like a factory or a copy constructor rather than a "mutator".

Now, you could argue that the name involved could be hacked in some
magical way, thus preserving the illusions that strings are mutable,
but what happens when a name is not involved?

s.append(sometext) # s gets replaced
(text + moretext).append(sometext) # what gets replaced?

Mutability is more than a mere implementation detail: in imperative
languages, it's probably one of the most underrated mechanisms
influencing the correct behaviour of programs.

Paul