how are strings immutable in python?

[ssecorp]

>>h = "aja baja"

>>h += 'e'
h

'aja bajae'

>>>

[Peter Otten]

ssecorp wrote:

>>>h = "aja baja"
h += 'e'
h

'aja bajae'

>>>>

The inplace-add operator doesn't mutate the lvalue, it just rebinds it:

>>a = b = "foo"
id(a)

47643036142016

>>a += "bar"
id(a), a

(47643036142064, 'foobar')

>>id(b), b

(47643036142016, 'foo')

Peter

[Mel]

ssecorp wrote:

>>>h = "aja baja"
h += 'e'
h

'aja bajae'

>>>>

What Peter said, or, to put it another way:

Python 2.5.2 (r252:60911, Apr 21 2008, 11:12:42)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

>>a = b = "aja baja"
a += "e"
print a

aja bajae

>>print b

aja baja

Mutability/immutability makes a difference in programs when different
symbols (or container items) share a value.
Mel.

[Terry Reedy]

Peter Otten wrote:

ssecorp wrote:

>>>>h = "aja baja"
h += 'e'
h

'aja bajae'

The inplace-add operator doesn't mutate the lvalue, it just rebinds it:

In Python, neither '=' nor members of the 'op=' family are operators.
They all mark *assignment* or *augmented assignment* statements that
*all* bind objects to targets.

Augmented assignments are, rather obviously, restricted to binding one
object to one target. For 'x op= y', if the object originally bound to
x is mutable, the arithmetic operation part of the augmented assignment
can (should) be implemented by an inplace __i<opname>__ special method
that (normally, but not necessarily) mutates and returns self to be
rebound. Otherwise, the interpreter calls the normal __<opname>__
special method (if it exits) that returns a new object to be bound.

Thus, '+=' is neither an operator nor is the indicated operation
necessarily inplace.

Immutable built-in classes do not have __i<opname>__ methods. So given
that name h is bound to a string,
h += 'e'
has exactly the same effect as
h = h + 'e'
which has exactly the same effect as
h = h.__add__('e')
The same is true for immutable instances of other built-in classes.
Terry Jan Reedy

[ssecorp]

so if strings were mutable and i did
a = b = "foo"
and then did
a += "bar"
then a and b would be foobar?

[Mark Tolonen]

"ssecorp" <ci**********@gmail.comwrote in message
news:a0**********************************@z72g2000 hsb.googlegroups.com...

so if strings were mutable and i did
a = b = "foo"
and then did
a += "bar"
then a and b would be foobar?

This can be demonstrated with a list of characters, which *is* mutable:

>>a = b = list('foo')
a += list('bar')
a

['f', 'o', 'o', 'b', 'a', 'r']

>>b

['f', 'o', 'o', 'b', 'a', 'r']

--Mark

[ssecorp]

so why would you ever want mutability?
seems very counterintuitive and unreliable.

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

so why would you ever want mutability?

>

seems very counterintuitive and unreliable.

For lists, mutability is fairly natural.

Suppose you have a function f that copies
some items from one list to another. You write it
as

def f(src, dst):
for x in src:
if condition(x):
dst.append(x)

If dst was immutable, an .append method could not
be defined (since it modifies the list itself), so
you would have to write

dst = dst + [x]

However, that would only modify the local variable
dst in the function f - the parameter of the caller
of f would not get modified.

The same holds for many other operations on lists.
You can pass very complex data structures around
(lists of lists of dictionaries etc), and have functions
modify the lists, rather than creating new ones.

For example, to change a two-dimensional matrix
(which is a list of lists), you can write

M[10][11] = 3.14

whereas with immutable lists, you would have to write

M_10_new = M[10][:11] + [3.14] + [M10][12:]
M = M[:10] + [M_10_new] + M[11:]

HTH,
Martin

[Lie]

On Jul 7, 1:45*am, ssecorp <[e-mail]:

>h = "aja baja"

# 'aja baja' is created and assigned to the name h

>h += 'e'

# Is the equivalent of:
# h = h + 'e'
#
# In there, a h and 'e' is concatenated and assigned to
# a new string object which is bound to h. The
# original string object which contains
# 'aja baja' is "garbage collected"[1].

>h

# printing h which contains the new string object containing 'aja
bajae'

'aja bajae'

[1] actually python uses reference counting first to choose which
object to delete