By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,454 Members | 3,191 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,454 IT Pros & Developers. It's quick & easy.

When are immutable tuples *essential*? Why can't you just use lists *everywhere* instead?

P: n/a
Please help me think of an example where immutable tuples are
essential.

It seems that everywhere a tuple is used one could just as easily use
a list instead.

chris

Apr 20 '07 #1
Share this Question
Share on Google+
27 Replies


P: n/a
se******@spawar.navy.mil wrote:
Please help me think of an example where immutable tuples are
essential.
When used as dictionary keys (also everywhere else where they must
be in a constant order).

Yes, this *is* used in practice.

Regards,
Björn

--
BOFH excuse #14:

sounds like a Windows problem, try calling Microsoft support

Apr 20 '07 #2

P: n/a
On Apr 20, 2:06 pm, "seber...@spawar.navy.mil"
<seber...@spawar.navy.milwrote:
Please help me think of an example where immutable tuples are
essential.

It seems that everywhere a tuple is used one could just as easily use
a list instead.

chris

I don't remember exactly where I read about it, but Guido said once
that tuples are being kept mainly for historical reasons.
This is what Python uses internally from the beginning and it's just
an implementation detail that makes sense in some contexts.
Although I guess you can ignore them and use only lists instead if you
want..

luis

Apr 20 '07 #3

P: n/a
Luis M. González wrote:
I don't remember exactly where I read about it, but Guido said
once that tuples are being kept mainly for historical reasons.
Weren't tuples added when lists already existed?

Regards,
Björn

--
BOFH excuse #101:

Collapsed Backbone

Apr 20 '07 #4

P: n/a
Iou need only consider having cartesian coordinate sets as the keys
for an example. A 2 dimensional list might be overly expensive if your
coordinates span a large area but are relatively sparse.

Apr 20 '07 #5

P: n/a
En Fri, 20 Apr 2007 15:28:51 -0300, Bjoern Schliessmann
<us**************************@spamgourmet.comescri bió:
Luis M. González wrote:
>I don't remember exactly where I read about it, but Guido said
once that tuples are being kept mainly for historical reasons.

Weren't tuples added when lists already existed?
Both listobject.c and tupleobject.c appear to had been checked in at the
same time:

Revision 2167 - (view) (download) (as text) - [select for diffs]
Added Sun Oct 14 12:07:46 1990 UTC (16 years, 6 months ago) by guido
File length: 4965 byte(s)
Initial revision

And that's before the earliest tagged release I could find on svn, Python
0.98

--
Gabriel Genellina
Apr 20 '07 #6

P: n/a
On Apr 20, 3:28 pm, Bjoern Schliessmann <usenet-
mail-0306.20.chr0n...@spamgourmet.comwrote:
Luis M. González wrote:
I don't remember exactly where I read about it, but Guido said
once that tuples are being kept mainly for historical reasons.

Weren't tuples added when lists already existed?

Regards,

Björn

--
BOFH excuse #101:

Collapsed Backbone
I tried googling for these comments, but I couldn't find them.
Perhaps I never read them and it was just my imagination...
Anyway, I suggest reading this chapter of "Dive into Python" for a
good explanation of the differences between tuples and lists:
http://diveintopython.org/native_data_types/tuples.html

The article explains that, amongst other things, tuples are faster
than lists, so if you are working with constant values (inmutables)
they are more indicated than lists.

luis
Apr 20 '07 #7

P: n/a
On Apr 20, 6:09 pm, Bjoern Schliessmann <usenet-
mail-0306.20.chr0n...@spamgourmet.comwrote:
seber...@spawar.navy.mil wrote:
Please help me think of an example where immutable tuples are
essential.

When used as dictionary keys (also everywhere else where they must
be in a constant order).

Yes, this *is* used in practice.
Yup - using tuples as dictionary keys is very common.

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml
Regards,

Björn

--
BOFH excuse #14:

sounds like a Windows problem, try calling Microsoft support

Apr 20 '07 #8

P: n/a

The article explains that, amongst other things, tuples are faster
than lists, so if you are working with constant values (inmutables)
they are more indicated than lists.
Thanks. I thought Python's design wasn't so concerned with
optimizations.
Adding a new type "just" for optimization reasons seems perhaps
unnecessary. I could be wrong.

Apr 20 '07 #9

P: n/a
On Apr 21, 7:09 am, Luis M. González <luis...@gmail.comwrote:
On Apr 20, 3:28 pm, Bjoern Schliessmann <usenet-

mail-0306.20.chr0n...@spamgourmet.comwrote:
Luis M. González wrote:
I don't remember exactly where I read about it, but Guido said
once that tuples are being kept mainly for historical reasons.
Weren't tuples added when lists already existed?
Regards,
Björn
--
BOFH excuse #101:
Collapsed Backbone

I tried googling for these comments, but I couldn't find them.
Perhaps I never read them and it was just my imagination...
Anyway, I suggest reading this chapter of "Dive into Python" for a
good explanation of the differences between tuples and lists:http://diveintopython.org/native_data_types/tuples.html

The article explains that, amongst other things, tuples are faster
than lists, so if you are working with constant values (inmutables)
they are more indicated than lists.
One inessential but very useful thing about tuples when you have a lot
of them is that they are allocated the minimum possible amount of
memory. OTOH lists are created with some slack so that appending etc
can avoid taking quadratic time.

Apr 20 '07 #10

P: n/a
On Apr 20, 4:37 pm, John Machin <sjmac...@lexicon.netwrote:
One inessential but very useful thing about tuples when you have a lot
of them is that they are allocated the minimum possible amount of
memory. OTOH lists are created with some slack so that appending etc
can avoid taking quadratic time.
Speaking of inessential but very useful things, I'm also a big fan of
the tuple swap...
a = 2
b = 3
(a, b) = (b, a)
print a # 3
print b # 2

As well as the simple return of multiple values from a single
function:

c_stdout, c_stdin = popen2("ls")

IMO, the biggest thing going for tuples is the syntactical sugar they
bring to Python. Doing either of these using lists or other data
constructs would not be nearly as clean as they are with tuples.

Apr 20 '07 #11

P: n/a
ga******@gmail.com wrote:
On Apr 20, 4:37 pm, John Machin <sjmac...@lexicon.netwrote:
>>One inessential but very useful thing about tuples when you have a lot
of them is that they are allocated the minimum possible amount of
memory. OTOH lists are created with some slack so that appending etc
can avoid taking quadratic time.


Speaking of inessential but very useful things, I'm also a big fan of
the tuple swap...
a = 2
b = 3
(a, b) = (b, a)
print a # 3
print b # 2
You can also do a list swap.

pya = 4
pyb = 2
py[a, b] = [b, a]
pya
2
pyb
4
Apr 20 '07 #12

P: n/a
On Fri, 20 Apr 2007 15:53:45 -0700, garrickp wrote:
Speaking of inessential but very useful things, I'm also a big fan of
the tuple swap...
a = 2
b = 3
(a, b) = (b, a)
Since tuples are made by commas, not brackets, that can be written more
cleanly as:

a, b = b, a

The only exception is the special case of an empty tuple, which can be
written as ().
IMO, the biggest thing going for tuples is the syntactical sugar they
bring to Python.
More important than the ability to use them as keys in dicts?
--
Steven.

Apr 21 '07 #13

P: n/a
On Fri, 20 Apr 2007 15:36:00 -0700, se******@spawar.navy.mil wrote:
>
>The article explains that, amongst other things, tuples are faster
than lists, so if you are working with constant values (inmutables)
they are more indicated than lists.

Thanks. I thought Python's design wasn't so concerned with
optimizations.
Adding a new type "just" for optimization reasons seems perhaps
unnecessary. I could be wrong.
It's times like this I want to cry...

>>adict = {(1,2): "parrot"}
Try replacing that tuple with a list. "Just optimization" my eye!
--
Steven.

Apr 21 '07 #14

P: n/a
ga******@gmail.com a écrit :
On Apr 20, 4:37 pm, John Machin <sjmac...@lexicon.netwrote:
>>One inessential but very useful thing about tuples when you have a lot
of them is that they are allocated the minimum possible amount of
memory. OTOH lists are created with some slack so that appending etc
can avoid taking quadratic time.


Speaking of inessential but very useful things, I'm also a big fan of
the tuple swap...
Which relies on unpacking, which also works with lists....
Apr 21 '07 #15

P: n/a
se******@spawar.navy.mil a écrit :
Please help me think of an example where immutable tuples are
essential.
Well, I don't know if they are "essential" - much of Python can be seen
as 'unessential' syntactic sugar (my, even the class statement is not
"essential" if you go that way).
It seems that everywhere a tuple is used one could just as easily use
a list instead.
Ever tried using a list as key in a dict ?

Apr 21 '07 #16

P: n/a
On 2007-04-20, Gabriel Genellina <ga*******@yahoo.com.arwrote:
En Fri, 20 Apr 2007 15:28:51 -0300, Bjoern Schliessmann
<us**************************@spamgourmet.comescr ibió:
>Luis M. González wrote:
>>I don't remember exactly where I read about it, but Guido said
once that tuples are being kept mainly for historical reasons.

Weren't tuples added when lists already existed?

Both listobject.c and tupleobject.c appear to had been checked in at the
same time:

Revision 2167 - (view) (download) (as text) - [select for diffs]
Added Sun Oct 14 12:07:46 1990 UTC (16 years, 6 months ago) by guido
File length: 4965 byte(s)
Initial revision

And that's before the earliest tagged release I could find on svn, Python
0.98
But this doesn't contradict the supposed comment from guido. One can
add something later and come to the conclusion that it would have been
better not included but that in the mean time too much depend on it
to remove it. That seems a perfect description of keeping something
for historical reasons.

So it is possible that one keeps something for historical reasons
that is more recent than something one keeps for design reasons.

--
Antoon Pardon
Apr 23 '07 #17

P: n/a
On 2007-04-21, Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrote:
On Fri, 20 Apr 2007 15:36:00 -0700, se******@spawar.navy.mil wrote:
>>The article explains that, amongst other things, tuples are
faster than lists, so if you are working with constant values
(inmutables) they are more indicated than lists.

Thanks. I thought Python's design wasn't so concerned with
optimizations. Adding a new type "just" for optimization
reasons seems perhaps unnecessary. I could be wrong.

It's times like this I want to cry...

>>>adict = {(1,2): "parrot"}

Try replacing that tuple with a list. "Just optimization" my eye!
So the question becomes: Why do Python dictionaries require keys
to be of an immutable type?

--
Neil Cerutti
Apr 23 '07 #18

P: n/a
On 23 Apr 2007 17:19:15 +0200, Neil Cerutti <ho*****@yahoo.comwrote:
So the question becomes: Why do Python dictionaries require keys
to be of an immutable type?
Dictionary keys are hashed values. If you change the key, you change
the hash and lose the pointer to the referenced object.

Or: Because. ;-)

Chris
--
"A little government and a little luck are necessary in life, but only
a fool trusts either of them." -- P. J. O'Rourke
Apr 23 '07 #19

P: n/a
On 2007-04-23, Chris Cioffi <ev********@gmail.comwrote:
On 23 Apr 2007 17:19:15 +0200, Neil Cerutti <ho*****@yahoo.com>
wrote:
>So the question becomes: Why do Python dictionaries require
keys to be of an immutable type?

Dictionary keys are hashed values. If you change the key, you
change the hash and lose the pointer to the referenced object.
Other dictionary-like implementations (C++ std::map for example)
simply exhort you not to change keys (C++ makes it hard to ignore
the exhortation) or suffer undefined behavior. Perhaps avoiding a
cause of undefined behavior was the Python reason for the
requirement.
Or: Because. ;-)
Heh, heh. I was wondering, if we dig deep enough, wether we'll
end up back at, "just an optimization," as the reason.

--
Neil Cerutti
Apr 23 '07 #20

P: n/a
En Mon, 23 Apr 2007 12:46:13 -0300, Neil Cerutti <ho*****@yahoo.com>
escribió:
On 2007-04-23, Chris Cioffi <ev********@gmail.comwrote:
>On 23 Apr 2007 17:19:15 +0200, Neil Cerutti <ho*****@yahoo.com>
wrote:
>>So the question becomes: Why do Python dictionaries require
keys to be of an immutable type?

Or: Because. ;-)

Heh, heh. I was wondering, if we dig deep enough, wether we'll
end up back at, "just an optimization," as the reason.
Fortran guys could make programs for a long time having arrays as their
ONLY structured type, so having a built in dictionary is not just an
optimization, it's a luxury! :)

--
Gabriel Genellina

Apr 23 '07 #21

P: n/a
Neil Cerutti wrote:
On 2007-04-21, Steven D'Aprano <st***@REMOVE.THIS.cybersource.com.auwrote:
>On Fri, 20 Apr 2007 15:36:00 -0700, se******@spawar.navy.mil wrote:
>>>The article explains that, amongst other things, tuples are
faster than lists, so if you are working with constant values
(inmutables) they are more indicated than lists.
Thanks. I thought Python's design wasn't so concerned with
optimizations. Adding a new type "just" for optimization
reasons seems perhaps unnecessary. I could be wrong.
It's times like this I want to cry...

>>>>adict = {(1,2): "parrot"}
Try replacing that tuple with a list. "Just optimization" my eye!

So the question becomes: Why do Python dictionaries require keys
to be of an immutable type?
Because otherwise people would expect to be able to use a list to select
a dictionary entry even after they'd modified elements of the list after
creating the dictionary entry. Which they couldn't. So Python doesn't
let them use lists.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Recent Ramblings http://holdenweb.blogspot.com

Apr 23 '07 #22

P: n/a
On 2007-04-23, Steve Holden <st***@holdenweb.comwrote:
Neil Cerutti wrote:
>So the question becomes: Why do Python dictionaries require
keys to be of an immutable type?

Because otherwise people would expect to be able to use a list
to select a dictionary entry even after they'd modified
elements of the list after creating the dictionary entry. Which
they couldn't. So Python doesn't let them use lists.
The interpreter explains it: "A list is not a hashable object."
Choosing a hash table instead of some kind of balanced tree seems
to be just an optimization. ;)

--
Neil Cerutti
Apr 23 '07 #23

P: n/a
Neil Cerutti wrote:
The interpreter explains it: "A list is not a hashable object."
Choosing a hash table instead of some kind of balanced tree seems
to be just an optimization. ;)
Even with a balanced tree, if a key in a node changes value, you may
have to re-balance the tree. Nothing in a Python list says that a
dictionary tree would have to be re-balanced if you changed that
particular list.

Mel.

Apr 24 '07 #24

P: n/a
On Apr 23, 10:38 pm, Mel Wilson <mwil...@the-wire.comwrote:
Neil Cerutti wrote:
The interpreter explains it: "A list is not a hashable object."
Choosing a hash table instead of some kind of balanced tree seems
to be just an optimization. ;)

Even with a balanced tree, if a key in a node changes value, you may
have to re-balance the tree. Nothing in a Python list says that a
dictionary tree would have to be re-balanced if you changed that
particular list.

Mel.
You don't have to look at any implementation. A dictionary maps every
key to exactly one object. If the objects were mutable, you could
change one key to another key, and then which item would the
dictionary pull?
(Imaginary code)
d = {[1,2,3]: 'hat', [1,2,4]: 'sock' }
for key in d:
key.pop()
print d[[1,2]] #does this print hat or sock?

Sets have the same problem. A set can't have duplicates; how could
you enforce this with mutable objects?

Tom

Apr 24 '07 #25

P: n/a
On 2007-04-24, Thomas Nelson <th*@mail.utexas.eduwrote:
On Apr 23, 10:38 pm, Mel Wilson <mwil...@the-wire.comwrote:
>Even with a balanced tree, if a key in a node changes value,
you may have to re-balance the tree. Nothing in a Python list
says that a dictionary tree would have to be re-balanced if
you changed that particular list.

You don't have to look at any implementation. A dictionary
maps every key to exactly one object. If the objects were
mutable, you could change one key to another key, and then
which item would the dictionary pull?
(Imaginary code)
d = {[1,2,3]: 'hat', [1,2,4]: 'sock' }
for key in d:
key.pop()
print d[[1,2]] #does this print hat or sock?
That would be documented as undefined behavior, and users
exhorted not to do such things.

Python's dictionaries are a proven winner--I'm definitely not an
advocate for changing them. But the general requirement for a
mapping container *isn't* that keys be immutable, but that you
either don't mutate keys, or don't do so without also reording
(rehashing?) the mapping.

--
Neil Cerutti
Apr 25 '07 #26

P: n/a
Neil Cerutti wrote:
On 2007-04-24, Thomas Nelson <th*@mail.utexas.eduwrote:
>On Apr 23, 10:38 pm, Mel Wilson <mwil...@the-wire.comwrote:
>>Even with a balanced tree, if a key in a node changes value,
you may have to re-balance the tree. Nothing in a Python list
says that a dictionary tree would have to be re-balanced if
you changed that particular list.
You don't have to look at any implementation. A dictionary
maps every key to exactly one object. If the objects were
mutable, you could change one key to another key, and then
which item would the dictionary pull?
(Imaginary code)
d = {[1,2,3]: 'hat', [1,2,4]: 'sock' }
for key in d:
key.pop()
print d[[1,2]] #does this print hat or sock?

That would be documented as undefined behavior, and users
exhorted not to do such things.

Python's dictionaries are a proven winner--I'm definitely not an
advocate for changing them. But the general requirement for a
mapping container *isn't* that keys be immutable, but that you
either don't mutate keys, or don't do so without also reording
(rehashing?) the mapping.
And which API do you use to "reord(er?) (rehash) the mapping"?

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Recent Ramblings http://holdenweb.blogspot.com

Apr 25 '07 #27

P: n/a
On 2007-04-25, Steve Holden <st***@holdenweb.comwrote:
Neil Cerutti wrote:
>That would be documented as undefined behavior, and users
exhorted not to do such things.

Python's dictionaries are a proven winner--I'm definitely not an
advocate for changing them. But the general requirement for a
mapping container *isn't* that keys be immutable, but that you
either don't mutate keys, or don't do so without also reording
(rehashing?) the mapping.
And which API do you use to "reord(er?) (rehash) the mapping"?
A pretty complex an unnecessary one, I'd guess. ;) Since you
would most likely need to remove the changed key from the
mapping, and then reinsert the new one, it's just as well to
leave the whole process entirely up to the user.

Which is how Python currently works. ;)

--
Neil Cerutti
Apr 25 '07 #28

This discussion thread is closed

Replies have been disabled for this discussion.