Mutable strings - symetry with list types

[Gordon Airport]

Andy Jewell wrote:

> 
> Mutable strings are one thing that I missed, initially, when I first started 
> using Python.  After a while, as the "Pythonic" way of doing things sank in, 
> I realised that Python doesn't *need* mutable strings.
> 

Well...it doesn't /need/ the simple expressions that were given to alot 
of things.

> Python strings (and integers and floats) are all immutable for a very good 
> reason:  dictionaries can't reliably use mutable objects as keys.  

And I'm not suggesting doing away with immutable strings.

> At first, 
> this seemed rather like "the tail wagging the dog"...  however, once I fully 
> understood the % (percent) string operator, and the ability to efficiently 
> convert strings into lists and back, my anxiety went away.   These cover most 
> usage of strings that might convince you you need mutability.
>

Yeah, you /can/ do everything, it's a question of clarity. You see how 
often ' '.join( blah ) is the answer to people's questions here, it's 
not obvious and it looks like a hack, IMO. Plus you can't do
somestring = '%s %s %s' % [ 'nine', 'bladed', 'sword' ]
The extra steps in list(somestring) ... ''.join( somestring ) are what 
could be removed I guess.

> As for the suggestion that the kind of quote used should determine whether or 
> not a string is mutable, I sort of /half/ agree.  On one hand, making (say) 
> the apostrophe mean mutable and the double quote mean immutable would break 
> thousands of existing applications - for end users, "a simple search and 
> replace" is simply not feasable!  

I'm less sure about that now, but the important point is that you would 
know that all old string delimiters would be changed to the immutable 
one. I'll try to come up with a regex.

Furthermore, the meaning of the following
> snippet would be subtly (and possibly dangerously) changed:
> 
> ----8<-----
>     s1="this is an 'immutable' string"
>     s2='this is a "mutable" string'
> 
>     s3=s1.replace("'",'"')+" and "+s2.replace('"','"')   # replace quotes with
>    # apostrophes and vice-versa
>
 >
>     d1={s3:(s1,s2)}
> ----8<-----
> 
> Q1) What type will s3 be?
> Q2) What happens to s2?  As it's mutable, shouldn't it do the replacement 
> "in-line"?
> Q3) Will the assignment of d1 succeed?  If it fails, wouldn't that be 
> confusing?
> 

I think these problems can be avoided if you just escape both symbols 
within both types of string. This complicates the code conversion, of 
course.

> On the other hand, Python already has this type distinction for raw and 
> unicode strings (r"..." and u"...", respectively).  If it were to be adopted, 
> I would be ok with an m"..." type of string, which could be barred from being 
> a dictionary key.   This would open up a can of worms wrt the other immutable 
> types, too: would we end up with:
> 
> ----8<-----
>     a=1234567m # a mutable integer
>     b=1234567.89m # a mutable float
>     c=123456789012345678901234567890Lm # a mutable long integer
>     d=123+456jm # a mutable complex number
>     e=m(1,2,3,4,5,6,"a","b","c") # a mutable tuple !!! :-p
> ----8<-----

I don't understand what a mutable numeric type would be. I just want a 
string type that I can directly treat as an array of characters; numeric 
types aren't indexable.

> 
> This could start a flame-war/heated debate on the scale of the ternary 
> operator PEP!

Viva la ?:! ;-)

> 
> Maybe there's a project for you (and a good introduction to a practical 
> application for new-style Python classes to boot)!  
> 
> I'm sure people have written this type of thing in the past - and in some 
> situations, it's bound to be useful, but I think it should be kept as a 
> separate module, so that you have to *declare* your usage of this /strange/ 
> behaviour to the reader; "explicit is better than implicit".

Think of it as a symetry with the mutable and immutable list types we 
already have. It is kind of strange, but we learn their applications and 
deal with it. What's the balance of what shows up in code? I suspect 
that in gross terms there's more (mutable) list use than (immutable) 
tuple; mutable strings would have their place likewise.