473,320 Members | 1,831 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

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

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

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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

10
by: Ivan Voras | last post by:
Are there any performance/size differences between using tuples and using lists? -- -- Every sufficiently advanced magic is indistinguishable from technology - Arthur C Anticlarke
1
by: Anne Wangnick | last post by:
Dear all, I don't get why the index() method is only defined for mutable sequence types. This is not what I expected. Shouldn't this be added in Python? Is there such a PEP already? Regards,...
5
by: Chris | last post by:
Hi Consider the following tuples: >>> t = (,) >>> u = (1,2) >>> v = ('1','2') >>> t (, ) >>> u (1, 2)
7
by: Torsten Mohr | last post by:
Hi, reading the documentation (and also from a hint from this NG) i know now that there are some types that are not mutable. But why is it this way? From an overhead point of view i think...
14
by: Richard | last post by:
I have a large list of two element tuples. I want two separate lists: One list with the first element of every tuple, and the second list with the second element of every tuple. Each tuple...
90
by: Ben Finney | last post by:
Howdy all, How can a (user-defined) class ensure that its instances are immutable, like an int or a tuple, without inheriting from those types? What caveats should be observed in making...
66
by: Mike Meyer | last post by:
It seems that the distinction between tuples and lists has slowly been fading away. What we call "tuple unpacking" works fine with lists on either side of the assignment, and iterators on the...
12
by: John Henry | last post by:
Hi list, Just to make sure I understand this. Since there is no "pointer" type in Python, I like to know how I do that. For instance, if I do: ...some_huge_list is a huge list...
122
by: C.L. | last post by:
I was looking for a function or method that would return the index to the first matching element in a list. Coming from a C++ STL background, I thought it might be called "find". My first stop was...
0
by: DolphinDB | last post by:
The formulas of 101 quantitative trading alphas used by WorldQuant were presented in the paper 101 Formulaic Alphas. However, some formulas are complex, leading to challenges in calculation. Take...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
0
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.