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 -- http://mail.python.org/mailman/listinfo/python-list
