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

[seberino]

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

 

[Bjoern Schliessmann]

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

 

[=?iso-8859-1?q?Luis_M=2E_Gonz=E1lez?=]

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

 

[Bjoern Schliessmann]

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

 

[pdpi]

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.

 

[Gabriel Genellina]

En Fri, 20 Apr 2007 15:28:51 -0300, Bjoern Schliessmann

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

 

[=?iso-8859-1?q?Luis_M=2E_Gonz=E1lez?=]

Weren't tuples added when lists already existed?

Regards,

Björn

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

 

[Fuzzyman]

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

 

[seberino]

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.

 

[John Machin]

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.

 

[garrickp]

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.

 

[James Stroud]

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.

py> a = 4
py> b = 2
py> [a, b] = [b, a]
py> a
2
py> b
4

 

[Steven D'Aprano]

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 D'Aprano]

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


Try replacing that tuple with a list. "Just optimization" my eye!

 

[Bruno Desthuilliers]

(e-mail address removed) a écrit :

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

 

[Bruno Desthuilliers]

(e-mail address removed) 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 ?

 

[Antoon Pardon]

En Fri, 20 Apr 2007 15:28:51 -0300, Bjoern Schliessmann

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.

 

[Neil Cerutti]

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



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?

 

[Chris Cioffi]

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

 

[Neil Cerutti]

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.