"Paul Boddie" <[EMAIL PROTECTED]> Wrote:
| 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
Lovely - this is exactly what I am thinking about...
|
| 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?
nothing really - this thing standing on its own is kind of "outside" the
language - If I do not have a name for you, I can't order you about - and the
same is true here - the result is just a string that is used wherever its
needed, as a literal would be : "this is a string" + " Here is some more"
("is" being used in the sense of "should be" - we are talking hypothetics here
and not how stuff actually "is")
|
| 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
This could be true - its just that, as an assembler type person - the notion
that some parts of memory is "cast in concrete" is kind of strange to me...
I understand that when you do something like giving a dict a key and tie a value
to the key - its dangerous to change the key - it would be a very smart
implementation indeed that can track the changes to such a key - but I can see
no value in solving the problem by making the key "Immutable" - it is a natural
consequence (at least in my mind) that when you store something in one way, you
have to use exactly the same way to retrieve it - but I don't think it should be
a language rule to try to protect a programmer from his own stupidity in such
cases -
so if I do something like:
PaulsName = "Paul Buddie"
and I use that as a key in my telephone directory,
and then I see the error, and I do
PaulsName = "Paul Boddie"
and I try to get at the information I have stored earlier, using the same
symbolic name - it aint gonna work...
And I accept this - its not what I am on about - I still think it would be nicer
if there were these commands to do the prepend insert append job, instead of
doing it laboriously using slicing.
(Aside: note that in the above the "value" tied to the symbolic name "PaulsName"
has actually changed - so what is immutable about it from this perspective? if
I can do this - why bother with immutability? )
Think for instance of the hoops you have to jump through to calculate the
checksum on an Intel hex, or Motorola s file, and to make a string that you can
write to a file or send to a serial port...
Thanks for the reasoned reply, btw - I appreciate it!
- Hendrik
--
http://mail.python.org/mailman/listinfo/python-list
