Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Mutable strings

Reply
Thread Tools

Mutable strings

 
 
Gordon Airport
Guest
Posts: n/a
 
      09-20-2003
Has anyone suggested introducing a mutable string type (yes, of course)
and distinguishing them from standard strings by the quote type - single
or double? As far as I know ' and " are currently interchangeable in all
circumstances (as long as they're paired) so there's no overloading to
muddy the language. Of course there could be some interesting problems
with current code that doesn't make a distinction, but it would be dead
easy to fix with a search-and-replace. And which would be the default
return type for functions returning strings...
It looks like there are ways of handling this by digging around in the
modules for more basic types, but it would be much nicer to have it
available at 'user level'.

 
Reply With Quote
 
 
 
 
Andy Jewell
Guest
Posts: n/a
 
      09-20-2003
On Saturday 20 Sep 2003 6:40 pm, Gordon Airport wrote:
> Has anyone suggested introducing a mutable string type (yes, of course)
> and distinguishing them from standard strings by the quote type - single
> or double? As far as I know ' and " are currently interchangeable in all
> circumstances (as long as they're paired) so there's no overloading to
> muddy the language. Of course there could be some interesting problems
> with current code that doesn't make a distinction, but it would be dead
> easy to fix with a search-and-replace. And which would be the default
> return type for functions returning strings...
> It looks like there are ways of handling this by digging around in the
> modules for more basic types, but it would be much nicer to have it
> available at 'user level'.



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.

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

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! 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={s3s1,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?

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<-----

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

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".

Remember, Mohammed had to go *to* the mountain, not the other way round!

hth,
-andyj




 
Reply With Quote
 
 
 
 
Peter Hansen
Guest
Posts: n/a
 
      09-20-2003
Gordon Airport wrote:
>
> Has anyone suggested introducing a mutable string type (yes, of course)
> and distinguishing them from standard strings by the quote type - single
> or double? As far as I know ' and " are currently interchangeable in all
> circumstances (as long as they're paired) so there's no overloading to
> muddy the language. Of course there could be some interesting problems
> with current code that doesn't make a distinction,


> but it would be dead easy to fix with a search-and-replace.

^^^^^^^^^^^^^^^^^^^^^^^^^
No, it definitely would not. You would also have to account for
embedded quotation marks that are not escaped already, and I'm
certain there are other complications.

It might be worth your writing a PEP, however, if only so that the
idea could be killed and buried for good.

-Peter
 
Reply With Quote
 
Gordon Airport
Guest
Posts: n/a
 
      09-21-2003
Peter Hansen wrote:

snip good points that I suspect could be handled with a fairly simple
regex

> It might be worth your writing a PEP, however, if only so that the
> idea could be killed and buried for good.
>


Yeah, I didn't see one already but I kind of expected this response.
Still, it didn't put a stake in the heart of the ternary operator
issue.


 
Reply With Quote
 
Gordon Airport
Guest
Posts: n/a
 
      09-21-2003
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={s3s1,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.

 
Reply With Quote
 
Dennis Lee Bieber
Guest
Posts: n/a
 
      09-21-2003
Gordon Airport fed this fish to the penguins on Sunday 21 September
2003 02:10 pm:


>
> 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


Prior to the creation of string methods, you'd have done

import string

.... string.join(blah, ' ')


> not obvious and it looks like a hack, IMO. Plus you can't do
> somestring = '%s %s %s' % [ 'nine', 'bladed', 'sword' ]


If you know both sides have equal numbers of terms (the %s matches the
number of entries in the list) you /can/ do a minor modification to
that line:

somestring = "%s %s %s" % tuple(["nine", "bladed", "sword"])

Of course, you could also create a dictionary and store those as
attributes (though to my mind, you have a sword with one modifier
"nine-bladed"; as is it could be interpreted to mean nine
bladed-sword(s) -- though all swords are bladed...).

>>> weapon = {"type":"Sword", "attribute":"bladed", "modifier":"nine"}
>>> weapon

{'attribute': 'bladed', 'modifier': 'nine', 'type': 'Sword'}
>>> somestring = "%(modifier)s %(attribute)s %(type)s" % weapon
>>> somestring

'nine bladed Sword'



--
> ================================================== ============ <
> http://www.velocityreviews.com/forums/(E-Mail Removed) | Wulfraed Dennis Lee Bieber KD6MOG <
> (E-Mail Removed) | Bestiaria Support Staff <
> ================================================== ============ <
> Bestiaria Home Page: http://www.beastie.dm.net/ <
> Home Page: http://www.dm.net/~wulfraed/ <


 
Reply With Quote
 
Peter Hansen
Guest
Posts: n/a
 
      09-22-2003
Gordon Airport wrote:
>
> Peter Hansen wrote:
>
> snip good points that I suspect could be handled with a fairly simple
> regex


I'd argue the point, but I guess until you try it, we'll never know. <wink>

> > It might be worth your writing a PEP, however, if only so that the
> > idea could be killed and buried for good.

>
> Yeah, I didn't see one already but I kind of expected this response.
> Still, it didn't put a stake in the heart of the ternary operator
> issue.


Apparently it served its purpose quite well. The main problem before
the PEP and vote was that there was no PEP to point to when somebody
asked about it, so you could say "asked and answered... will not happen".

Now there is, and the few times the issue has come up since, someone
has fairly quickly pointed to the PEP each time, avoiding lengthier
discussion.

-Peter
 
Reply With Quote
 
Hans-Joachim Widmaier
Guest
Posts: n/a
 
      09-22-2003
Andy Jewell <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...

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


Mutable strings come to *my* mind whenever I have to play with huge
binary data. Working with tens of megabytes is inherently somewhat
slow.

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


All understood. But then, I don't want to use my 32-MB binary blob as
a key.

> 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.


Converting said blob 'efficiently' to a list is something that I
certainly would not call 'efficiently' - if not for the conversion
itself, then for the memory consumption as list.

I don't think strings are immutable because they ought to be that way
(e.g. some CS guru teaches that "mutable strings are the root of all
evil"). They're immutable because they allow them to be used as
dictionary keys. And it was found that this doesn't affect the
usefulness of the language too much.

Still, I can see a use for mutable strings. Or better, mutable binary
data, made up of bytes. (where 'byte' is the smallest individually
addressable memory unit blabla, ... you get the meaning. Just to not
invite nit-pickers on that term.)

> "explicit is better than implicit".


Yes, definitely: Let there be another type.

Byte-twiddlingly yours,
Hans-J.
 
Reply With Quote
 
Rob Tillotson
Guest
Posts: n/a
 
      09-22-2003
(E-Mail Removed) (Hans-Joachim Widmaier) writes:
> Still, I can see a use for mutable strings. Or better, mutable binary
> data, made up of bytes. (where 'byte' is the smallest individually
> addressable memory unit blabla, ... you get the meaning. Just to not
> invite nit-pickers on that term.)
>
>> "explicit is better than implicit".

>
> Yes, definitely: Let there be another type.


There already is one: array. Mutable blocks of bytes (or shorts,
longs, floats, etc.), usable in many places where you might otherwise
use a string (struct.unpack, writing to a file, etc.). It is not
quite a mutable string, but it does fit the bill for manipulating raw
bytes. For example, off the top of my head:

>>> import array
>>> a = array.array('B','abcdefg')
>>> a

array('B', [97, 98, 99, 100, 101, 102, 103])
>>> a[2:4] = array.array('B','12345')
>>> a

array('B', [97, 98, 49, 50, 51, 52, 53, 101, 102, 103])
>>> a.tostring()

'ab12345efg'

For times when you really need a mutable string, there is always
UserString.MutableString (not quite sure what version this first
appeared in) -- it isn't terribly efficient since it uses a regular
string internally to hold the data, but it gets the job done and if
you really need something faster it would be a fairly simple exercise
to rewrite it using an array instead.

--Rob

--
Rob Tillotson N9MTB <(E-Mail Removed)>
 
Reply With Quote
 
Alex Martelli
Guest
Posts: n/a
 
      09-22-2003
Hans-Joachim Widmaier wrote:
...
>> I realised that Python doesn't *need* mutable strings.

>
> Mutable strings come to *my* mind whenever I have to play with huge
> binary data. Working with tens of megabytes is inherently somewhat
> slow.


But mutable strings are not the best place to keep "huge binary
data". Lists of smaller blocks, arrays of bytes, and lists of
arrays can be much more appropriate data structures.


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

>
> All understood. But then, I don't want to use my 32-MB binary blob as
> a key.


Since you don't in fact need to use it in any of the ways typically
applicable only to strings, it doesn't need to be a string.


>> convert strings into lists and back, my anxiety went away. These cover
>> most usage of strings that might convince you you need mutability.

>
> Converting said blob 'efficiently' to a list is something that I
> certainly would not call 'efficiently' - if not for the conversion
> itself, then for the memory consumption as list.


A typical case might be one where the blob is, e.g., in fact made
up of 65K sectors of 512 bytes each. In this case, the extra memory
consumption due to keeping the blob in memory as a list of 65K small
strings rather than one big string is, I would guess, about 1%. So,
who cares? And similarly if the "substrings" are of different sizes,
just as long as you only have a few tens of thousands of such
substrings. It's quite unusual that the "intrinsic structure" of
the blob is in fact one big undifferentiated 32MB thingy -- when it
is, you're unlikely to need it in memory, or if you do you're
unlikely to be able to apply any processing mutation to it sensibly;
and for those unusual and unlikely cases, arrays of bytes are often
just fine (after all, C has nothing BUT arrays of bytes [or of other
fixed entities], yet it's quite suitable for some such processing).


> I don't think strings are immutable because they ought to be that way
> (e.g. some CS guru teaches that "mutable strings are the root of all
> evil"). They're immutable because they allow them to be used as
> dictionary keys. And it was found that this doesn't affect the
> usefulness of the language too much.


Wrong. Consider Java, even back from the very first version: it had
no dictionaries on which string might be keys, yet it still decided
to make its strings immutable. This should make it obvious that the
interest of using keys as dict keys cannot possibly be the sole
motivation for the decision to make strings immutable in a language.
Rather, the deeper motivation is connected to wanting strings to be
ATOMIC, ELEMENTARY types, just like numbers; and to lots of useful
practical returns of that choice. All you lose is the "ability" to
"confuse" (type-pun) between strings and arrays of bytes in many
situations, but that's an ability best lost in many cases. It's not
an issue of "evil" -- a close-to-the-hardware low-level language
like C has excellent reasons to choose a different, close-to-HW
semantics -- but in a higher-level language I think Python's and
Java's choice to have strings immutable works better than (e.g.)
Perl's and Ruby's to have them mutable.


> Still, I can see a use for mutable strings. Or better, mutable binary
> data, made up of bytes. (where 'byte' is the smallest individually
> addressable memory unit blabla, ... you get the meaning. Just to not
> invite nit-pickers on that term.)


Just "import array" and you have your "mutable binary data made up
of bytes". So, what's the problem? Type-punning between THAT type,
and strings, is just not all that useful.


>> "explicit is better than implicit".

>
> Yes, definitely: Let there be another type.


But, there IS one! So, hat's wrong with it...?!


Alex

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Mutable Strings - Any libraries that offer this? casebash Python 9 07-27-2009 12:36 AM
Strings, Strings and Damned Strings Ben C Programming 14 06-24-2006 05:09 AM
Are JavaScript strings mutable? Water Cooler v2 Javascript 12 04-20-2006 07:50 PM
Mutable strings Mystifier Ruby 19 01-14-2005 10:00 PM
RE: Mutable strings SBrunning@trisystems.co.uk Python 1 09-22-2003 09:31 PM



Advertisments