Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #66914 > unrolled thread

Can tuples be replaced with lists all the time?

Back to article view | Back to comp.lang.python

Contents

  Can tuples be replaced with lists all the time? Sam <lightaiyee@gmail.com> - 2014-02-22 20:06 -0800
    Re: Can tuples be replaced with lists all the time? Paul Rubin <no.email@nospam.invalid> - 2014-02-22 20:28 -0800
    Re: Can tuples be replaced with lists all the time? Chris Angelico <rosuav@gmail.com> - 2014-02-23 15:18 +1100
    Re: Can tuples be replaced with lists all the time? Ben Finney <ben+python@benfinney.id.au> - 2014-02-23 15:49 +1100
    Re: Can tuples be replaced with lists all the time? 88888 Dihedral <dihedral88888@gmail.com> - 2014-02-23 11:45 -0800
    Re: Can tuples be replaced with lists all the time? Roy Smith <roy@panix.com> - 2014-02-22 23:19 -0500
      Re: Can tuples be replaced with lists all the time? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-03-02 17:21 -0500
    Re: Can tuples be replaced with lists all the time? Grant Edwards <invalid@invalid.invalid> - 2014-02-23 17:07 +0000
      Re: Can tuples be replaced with lists all the time? Roy Smith <roy@panix.com> - 2014-02-23 12:48 -0500
        Re: Can tuples be replaced with lists all the time? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-01 21:20 +0000
        Re: Can tuples be replaced with lists all the time? Terry Reedy <tjreedy@udel.edu> - 2014-03-01 18:15 -0500

#66914 — Can tuples be replaced with lists all the time?

My understanding of Python tuples is that they are like immutable lists. If this is the cause, why can't we replace tuples with lists all the time (just don't reassign the lists)? Correct me if I am wrong.

[toc] | [next] | [standalone]

#66915

Sam <lightaiyee@gmail.com> writes:
> My understanding of Python tuples is that they are like immutable
> lists. If this is the cause, why can't we replace tuples with lists
> all the time (just don't reassign the lists)? 

You can do that a lot of the time but not always.  For example, you can
use a tuple as a dictionary key, but not a list, since keys are supposed
to be immutable.

[toc] | [prev] | [next] | [standalone]

#66916

On Sun, Feb 23, 2014 at 3:06 PM, Sam <lightaiyee@gmail.com> wrote:
> My understanding of Python tuples is that they are like immutable lists. If this is the cause, why can't we replace tuples with lists all the time (just don't reassign the lists)? Correct me if I am wrong.
>

One reason is performance/efficiency. If Python knows this is never
going to change, it can save some effort. But a more important reason
is hashability.

>>> mapping = {}
>>> key = (1,2)
>>> mapping[key] = "Hello"
>>> key = (1,3)
>>> mapping[key] = "World"
>>> key = (2,3)
>>> mapping[key] = "!"
>>> mapping
{(1, 2): 'Hello', (1, 3): 'World', (2, 3): '!'}

You can't do this with lists:

>>> key = [1,2]
>>> mapping[key]
Traceback (most recent call last):
  File "<pyshell#12>", line 1, in <module>
    mapping[key]
TypeError: unhashable type: 'list'

This is because any two tuples are either equal or not equal, they
can't be otherwise. I can create another tuple and look up something
in the above mapping:

>>> mapping[1,3]
'World'

But with lists, their equality can change.

>>> lst1 = [1,2]
>>> lst2 = [1,3]
>>> lst1 == lst2
False
>>> lst1[1] += 1
>>> lst1 == lst2
True
>>> lst1[1] += 1
>>> lst1 == lst2
False

So it would be very difficult and dangerous to try to use a list as a
dictionary key. The only safe way to do it is by identity, and that's
only useful in a very small set of situations. So Python happily
declares that a tuple can be a dict key and a list can't, and that's
now a key (if you'll excuse the pun) difference between them.

ChrisA

[toc] | [prev] | [next] | [standalone]

#66917

Sam <lightaiyee@gmail.com> writes:

> My understanding of Python tuples is that they are like immutable
> lists.

That's a common expression, but I think it's not a helpful way to think
of them.

Rather, the different sequence types have different semantic purposes:

* For representing a sequence where each item means exactly the same no
  matter which position it's in (a “homogeneous sequence”), use a list.

* For representing a sequence where the meaning of each item is strongly
  dependent on its position in the sequence (a “heterogeneous
  sequence”), use a tuple.

See <URL:http://docs.python.org/3/library/stdtypes.html> for the
official Python description of the type differences.

> If this is the cause, why can't we replace tuples with lists all the
> time (just don't reassign the lists)? Correct me if I am wrong.

Because we need to represent different semantic concepts in our code,
and have each type support the semantics with different operations.

-- 
 \     “I went camping and borrowed a circus tent by mistake. I didn't |
  `\      notice until I got it set up. People complained because they |
_o__)                           couldn't see the lake.” —Steven Wright |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#66947

On Sunday, February 23, 2014 12:06:13 PM UTC+8, Sam wrote:
> My understanding of Python tuples is that they are like immutable lists. If this is the cause, why can't we replace tuples with lists all the time (just don't reassign the lists)? Correct me if I am wrong.
======

OK, lets be serious about high-level
programming lnguages.

Python is a dynamical typed
( name binding mechnism implicitly),
imperative language with the built in auto GC and the heap plus stack 
managements in the bundled scriptor.

A tuple is treated immutable and
a list is mutable in Python.

I suggest one can read
the introductions about Erlang 
which is a non-imperative high 
level language in the 5 to 6 th gen
programming languages in back-end 
server applictions for the robustness
and maintainence costs.

Neverthless, Python is regarded as a programming firendly language 
when comparing with other high level 
languages. 


 

[toc] | [prev] | [next] | [standalone]

#67350

In article <64af70e3-6876-4fbf-8386-330d2f48735a@googlegroups.com>,
 Sam <lightaiyee@gmail.com> wrote:

> My understanding of Python tuples is that they are like immutable lists. If 
> this is the cause, why can't we replace tuples with lists all the time (just 
> don't reassign the lists)? Correct me if I am wrong.

There are many tasks for which either a list or a tuple would work fine.  
But, not all.  Basically:

If you need something which is hashable (i.e. to be used as a dictionary 
key), you need to use a tuple.

If you need something which you can mutate (say, to accumulate items as 
you go through a loop), then you need to use a list.

Beyond that, you get into religious territory.

[toc] | [prev] | [next] | [standalone]

#67473

On Sat, 22 Feb 2014 23:19:22 -0500, Roy Smith <roy@panix.com> declaimed the
following:


>
>Beyond that, you get into religious territory.

	To purloin from M. Lackey's Valdemar: There is no one true way!

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#67352

On 2014-02-23, Sam <lightaiyee@gmail.com> wrote:

> My understanding of Python tuples is that they are like immutable
> lists. If this is the cause, why can't we replace tuples with lists
> all the time (just don't reassign the lists)? Correct me if I am
> wrong.

In addition to the things related to one being mutable and the other
immutable, there is a certain tradition that often results in differnt
usages for them. 

Though it's certainly not required, lists are more often used as
variable length _homogeneous_ containers -- sort of like a variable
length array or linked list in C.  The "type" or "meaning" of element
#N is the same as that of element #M.

In constrast, tuples are often used as fixed-length heterogenous
containers (more like a struct in C except the fields are named 0, 1,
2, 3, etc.).  In a particular context, the Nth element of a tuple will
always mean one thing (e.g. a person's last name) while the Mth
element will always be something else (e.g. a person's age).

-- 
Grant

[toc] | [prev] | [next] | [standalone]

#67353

In article <led9s7$req$1@reader1.panix.com>,
 Grant Edwards <invalid@invalid.invalid> wrote:

> In constrast, tuples are often used as fixed-length heterogenous
> containers (more like a struct in C except the fields are named 0, 1,
> 2, 3, etc.).  In a particular context, the Nth element of a tuple will
> always mean one thing (e.g. a person's last name) while the Mth
> element will always be something else (e.g. a person's age).

And, of course, namedtuples make that much more explicit.

It also appears that tuples are more memory efficient.  I just ran some 
quick tests on my OSX box.  Creating a list of 10 million [1, 2, 3, 4, 
5] lists gave me a 1445 MB process.   The name number of (1, 2, 3, 4, 5) 
tuples was 748 MB.  I'm sure this is implementation dependent, but it 
seems plausible to assume similar results will be had on other 
implementations.

[toc] | [prev] | [next] | [standalone]

#67370

On 23/02/2014 17:48, Roy Smith wrote:
> In article <led9s7$req$1@reader1.panix.com>,
>   Grant Edwards <invalid@invalid.invalid> wrote:
>
>> In constrast, tuples are often used as fixed-length heterogenous
>> containers (more like a struct in C except the fields are named 0, 1,
>> 2, 3, etc.).  In a particular context, the Nth element of a tuple will
>> always mean one thing (e.g. a person's last name) while the Mth
>> element will always be something else (e.g. a person's age).
>
> And, of course, namedtuples make that much more explicit.
>
> It also appears that tuples are more memory efficient.  I just ran some
> quick tests on my OSX box.  Creating a list of 10 million [1, 2, 3, 4,
> 5] lists gave me a 1445 MB process.   The name number of (1, 2, 3, 4, 5)
> tuples was 748 MB.  I'm sure this is implementation dependent, but it
> seems plausible to assume similar results will be had on other
> implementations.
>

In CPython a list is overallocated so there's usually spare slots 
available if you want to add something to it.  In contrast you know when 
you create the tuple just how big it is so no overallocation is needed.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

[toc] | [prev] | [next] | [standalone]

#67391

On 3/1/2014 4:20 PM, Mark Lawrence wrote:
> On 23/02/2014 17:48, Roy Smith wrote:

>> It also appears that tuples are more memory efficient.  I just ran some
>> quick tests on my OSX box.  Creating a list of 10 million [1, 2, 3, 4,
>> 5] lists gave me a 1445 MB process.   The name number of (1, 2, 3, 4, 5)
>> tuples was 748 MB.  I'm sure this is implementation dependent, but it
>> seems plausible to assume similar results will be had on other
>> implementations.

The numbers sound right.

> In CPython a list is overallocated so there's usually spare slots
> available if you want to add something to it.  In contrast you know when
> you create the tuple just how big it is so no overallocation is needed.

Besides which, in CPython, a tuple is one block of memory, with a 
PyObject header followed by the object references, while a list uses 2 
blocks of memory. The first has a PyObject header, followed by a 
reference to the list block, its allocated length (minimum 8 I believe), 
and its current in-use length. The over-allocated list block, which must 
also start on a 4 or 8 byte alignment boundary, has the object 
references plus extra space.


-- 
Terry Jan Reedy

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web