[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.python

Immutable and Mutable Types

Bernard Lim

3/17/2008 6:24:00 AM

Hi,

I'm reading the Python Reference Manual in order to gain a better understanding
of Python under the hood.

On the last paragraph of 3.1, there is a statement on immutable and mutable
types as such:

<paraphrase>
Depending on implementation, for immutable types, operations that compute
new values may or may not actually return a reference to any existing object
with the same type and value, while for mutable objects this is (strictly)?
not allowed.
</paraphrase>

Using the example given in 3.1, how do I verify that this is true pertaining
to immutable types? Below is my understanding on verifying the above statement:

>>> a = 1
>>> b = 1
>>> a is b
True
>>> id(a)
10901000
>>> id(b)
10901000

Is this correct?

Regards
Bernard
6 Answers

Dan Bishop

3/17/2008 6:51:00 AM

0

Bernard Lim wrote:
> Hi,
>
> I'm reading the Python Reference Manual in order to gain a better understanding
> of Python under the hood.
>
> On the last paragraph of 3.1, there is a statement on immutable and mutable
> types as such:
>
> <paraphrase>
> Depending on implementation, for immutable types, operations that compute
> new values may or may not actually return a reference to any existing object
> with the same type and value, while for mutable objects this is (strictly)?
> not allowed.
> </paraphrase>
>
> Using the example given in 3.1, how do I verify that this is true pertaining
> to immutable types? Below is my understanding on verifying the above statement:
>
> >>> a = 1
> >>> b = 1
> >>> a is b
> True
> >>> id(a)
> 10901000
> >>> id(b)
> 10901000
>
> Is this correct?

Yes, that's correct. However,

>>> a = 100
>>> b = 100
>>> a is b
False
>>> id(a)
135644988
>>> id(b)
135645000

Ben Finney

3/17/2008 7:29:00 AM

0

Bernard Lim <bernard@blimyk.org> writes:

> <paraphrase>
> Depending on implementation, for immutable types, operations that
> compute new values may or may not actually return a reference to any
> existing object with the same type and value, while for mutable
> objects this is (strictly)? not allowed.
> </paraphrase>
>
> Using the example given in 3.1, how do I verify that this is true
> pertaining to immutable types?

You don't. By the language definition, it's entirely up to the
implementation whether *and when* to do this.

So, even if you find a particular session that does this, there's no
telling whether it'll stop happening at some future session using
*exactly the same inputs* -- and, if it did change, that would also be
entirely within the definition of the language.

If something in a language specification says "this set of conditions
leads to undefined behaviour", or "this aspect is implementation
defined", then *absolutely any behaviour* that fits the rest of the
definition is allowed, even if that results in non-determinism from
the programmer's perspective.

In short: Don't ever rely on such behaviour labelled with these "may
or may not" phrases, even if you run some tests and appear to get
predictable results.

--
\ â??The power of accurate observation is frequently called |
`\ cynicism by those who don't have it.â? â??George Bernard Shaw |
_o__) |
Ben Finney

cokofreedom

3/17/2008 8:33:00 AM

0

> >>> a = 1
> >>> b = 1
> >>> a is b
> True
> >>> id(a)
> 10901000
> >>> id(b)
> 10901000

Isn't this because integers up to a certain range are held in a single
memory location, thus why they are the same?

Duncan Booth

3/17/2008 10:02:00 AM

0

cokofreedom@gmail.com wrote:

>> >>> a = 1
>> >>> b = 1
>> >>> a is b
>> True
>> >>> id(a)
>> 10901000
>> >>> id(b)
>> 10901000
>
> Isn't this because integers up to a certain range are held in a single
> memory location, thus why they are the same?
>
Yes, in *some* implementations of Python this is exactly what happens. The
exact range, or indeed whether it happens at all, and (if it does happen)
whether the range depends on the phase of the moon are all undefined.

This, for example, is what I just got for a similar sequence:

>>> a = 1
>>> b = 5-4
>>> a is b
False
>>> id(a)
43L
>>> id(b)
44L
>>>

Diez B. Roggisch

3/17/2008 10:09:00 AM

0

cokofreedom@gmail.com wrote:

>> >>> a = 1
>> >>> b = 1
>> >>> a is b
>> True
>> >>> id(a)
>> 10901000
>> >>> id(b)
>> 10901000
>
> Isn't this because integers up to a certain range are held in a single
> memory location, thus why they are the same?

As the OP said:

<paraphrase>
Depending on implementation, for immutable types, operations that compute
new values may or may not actually return a reference to any existing object
with the same type and value, while for mutable objects this is (strictly)?
not allowed.
</paraphrase>

Which is exactly what happens - the actual implementation chose to cache
some values based on heuristics or common sense - but no guarantees are
made in either way.

Diez

Duncan Booth

3/17/2008 10:41:00 AM

0

"Diez B. Roggisch" <deets@nospam.web.de> wrote:

> Which is exactly what happens - the actual implementation chose to cache
> some values based on heuristics or common sense - but no guarantees are
> made in either way.

Here's a puzzle for those who think they know Python:

Given that I masked out part of the input, which version(s) of Python might
give the following output, and what might I have replaced by asterisks?

>>> a = 1
>>> b = 5-4
>>> if a is b: print 'yes!'
....
yes!
>>> b = ****
>>> if a is b: print 'yes!'
....
>>> b
1
>>> type(b)
<type 'int'>