Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Immutable and Mutable Types

Reply
Thread Tools

Immutable and Mutable Types

 
 
Bernard Lim
Guest
Posts: n/a
 
      03-17-2008
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


 
Reply With Quote
 
 
 
 
Dan Bishop
Guest
Posts: n/a
 
      03-17-2008
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
 
Reply With Quote
 
 
 
 
Ben Finney
Guest
Posts: n/a
 
      03-17-2008
Bernard Lim <(E-Mail Removed)> 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
 
Reply With Quote
 
cokofreedom@gmail.com
Guest
Posts: n/a
 
      03-17-2008
> >>> 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?
 
Reply With Quote
 
Duncan Booth
Guest
Posts: n/a
 
      03-17-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) 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
>>>

 
Reply With Quote
 
Diez B. Roggisch
Guest
Posts: n/a
 
      03-17-2008
(E-Mail Removed) 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
 
Reply With Quote
 
Duncan Booth
Guest
Posts: n/a
 
      03-17-2008
"Diez B. Roggisch" <(E-Mail Removed)> 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'>
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      03-17-2008
On Mon, 17 Mar 2008 10:40:43 +0000, Duncan Booth wrote:

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


There's too many variables -- at least five Python implementations that I
know of (CPython, Jython, PyPy, IronPython, and the Lisp-based
implementation that I can never remember the name of), and given that
this is an implementation-dependent feature it could have changed at any
time, in any version number (say, between minor releases). And there's
literally an infinite number of ways to get b equal to an int with the
value 1.

So I think unless somebody happens to have stumbled across this
behaviour, it's not predictable.

But having said that, I'm going to take a stab in the dark:

The line "b = ****" should be "b = int('1')"

and the version is CPython 1.4.

Am I close?


--
Steven
 
Reply With Quote
 
Stargaming
Guest
Posts: n/a
 
      03-17-2008
On Mon, 17 Mar 2008 10:40:43 +0000, Duncan Booth wrote:
> 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 = ****
>>>> if a is b: print 'yes!'

> ...
>>>> b

> 1
>>>> type(b)

> <type 'int'>


I know it! Using CPython 2.5.2a0, 2.6a1+ and 3.0a3+::

>>> b = type('type', (type,), {'__repr__': lambda self:

... "<type 'int'>"})('int', (object,), {'__repr__':
... lambda self:"1"})()
>>> b

1
>>> type(b)

<type 'int'>
>>> 1 is b

False

What's my prize?
 
Reply With Quote
 
Duncan Booth
Guest
Posts: n/a
 
      03-17-2008
Steven D'Aprano <(E-Mail Removed)> wrote:

> On Mon, 17 Mar 2008 10:40:43 +0000, Duncan Booth wrote:
>
>> 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?

>
> There's too many variables -- at least five Python implementations
> that I know of (CPython, Jython, PyPy, IronPython, and the Lisp-based
> implementation that I can never remember the name of), and given that
> this is an implementation-dependent feature it could have changed at
> any time, in any version number (say, between minor releases). And
> there's literally an infinite number of ways to get b equal to an int
> with the value 1.


True, there are a lot of variables, but perhaps not as many as you think.
For example, you can't get that output from IronPython or PyPy (or at least
not the versions I have kicking around) as they won't print 'yes!' for the
first test. You are correct though it is possible with both CPython and
Jython.

> So I think unless somebody happens to have stumbled across this
> behaviour, it's not predictable.
>
> But having said that, I'm going to take a stab in the dark:
>
> The line "b = ****" should be "b = int('1')"
>
> and the version is CPython 1.4.
>
> Am I close?
>

I don't have a copy of 1.4 to check so I'll believe you, but you can
certainly get the output I asked for with much more recent versions.

For the answer I actually want each asterisk substitutes for exactly one
character.
 
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
behavior difference for mutable and immutable variable in function definition jianbing.chen@gmail.com Python 5 05-05-2007 08:05 PM
Why mutable/immutable can't be valid class qualifier? hiwa Java 4 03-08-2006 04:46 PM
why are some types immutable? Torsten Mohr Python 7 01-17-2005 08:42 AM
Immutable sequence types lacking index() method Anne Wangnick Python 1 08-31-2004 07:19 PM
Newbie question: Returning mutable vs. immutable pugnatio2@yahoo.com Python 2 04-15-2004 02:57 PM



Advertisments