Why tuples and not lists?
init_...@my-dejanews.com
out the trivia from the FAQs.
I'm a little confused about tuples vs. lists -- with the exception of the
mutable/immutable thing, why would you pick one over the other? Is it a speed
thing?
From a lazy programmer's point of view, a list would seem the logical choice:
later on I might decide to add something smack in the middle of the thing and
with a tuple, I'd have to write a few extra lines of code.
Is this just one of those personal style questions? Like "import Whatsit" vs.
"import * from Whatsit"?
Yes, I did read FAQ 6.15. but I'm still unsure.
Fanks!
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Steinar Knutsen
<init_...@my-dejanews.com> wrote:
>I'm a little confused about tuples vs. lists -- with the exception of
>the mutable/immutable thing, why would you pick one over the other? Is
>it a speed thing?
Well, the (im)mutable «thing» is quite important, though. :) A tuple is
somewhat cheaper to construct than a list.
>From a lazy programmer's point of view, a list would seem the logical
>choice: later on I might decide to add something smack in the middle
>of the thing and with a tuple, I'd have to write a few extra lines of
>code.
list[i] = some_data
is a lot cheaper than
tuple = tuple[:i] + (some_data,) + tuple[i+1:]
>Is this just one of those personal style questions? Like "import
>Whatsit" vs. "import * from Whatsit"?
No, not really. (Guess I left out The Really Important Bit(TM) in there,
but I guess someone corrects me if I have. ;) )
--
Steinar
Mark Hammond
Think of tuples as C structures. It really doesnt make sense to insert
something in the middle of a C structure. Eg, a "rect" object is most
naturally described as a 4-ple (tuple of 4 items). Using a "list of
integers, whose length just happens to be 4" is not as obvious.
Think of lists as C arrays. Whenever you are returning a "list of
anything", use a list. You could never suggest that a rectangle is a "list
of integers". You may have a list of rectangles, etc, but it would be wrong
to suggest a list is conceptually like a "list of integers" at all.
The fact that Python implements these concepts in objects with such similar
semantics can cause confusion, but if you keep the above in mind, it should
become obvious what to use for what...
Mark.
init_...@my-dejanews.com wrote in message
<6q4b4a$r0j$1...@nnrp1.dejanews.com>...
>Ah, the joys of newbies. Always asking stupid questions and unable to
winkle
>out the trivia from the FAQs.
>
>I'm a little confused about tuples vs. lists -- with the exception of the
>mutable/immutable thing, why would you pick one over the other? Is it a
speed
>thing?
>
>From a lazy programmer's point of view, a list would seem the logical
choice:
>later on I might decide to add something smack in the middle of the thing
and
>with a tuple, I'd have to write a few extra lines of code.
>
>Is this just one of those personal style questions? Like "import Whatsit"
vs.
>"import * from Whatsit"?
>
Gordon McMillan
> Ah, the joys of newbies. Always asking stupid questions and unable
> to winkle out the trivia from the FAQs.
>
> I'm a little confused about tuples vs. lists -- with the exception
> of the mutable/immutable thing, why would you pick one over the
> other? Is it a speed thing?
You'll get used to it, and find yourself picking the right thing,
eventually. It might help to look at tuples as lazy structs. That is,
I have a function which returns a string, a float and an int. Then
return ("hello", 3.14159, 7)
makes more sense than
return ["hello", 3.1.159, 7]
> >From a lazy programmer's point of view, a list would seem the logical choice:
> later on I might decide to add something smack in the middle of the
> thing and with a tuple, I'd have to write a few extra lines of code.
If there's reason to add something to the middle, it should be a
list. If you want to use it as a dictionary key, it will have to be a
tuple (keys must be immutable). Otherwise, don't worry about it, it
will become clear with usage.
> Is this just one of those personal style questions? Like "import
> Whatsit" vs. "import * from Whatsit"?
Teach yourself NOW not to use "*", or you'll be teaching yourself
later! You almost never want everything, and it WILL trip you up. If
you don't want to qualify, spend a little extra time and do:
import Whatsit
foo = Whatsit.foo
bar = Whatsit.bar
Using "*" should be confined to interactive sessions, when you're
poking around. (Some well written modules go to some effort to make
it safe to use "*", but you've no reason to expect it!).
Reason: everything the imported module imports is now smack dab in
your namespace, ready to give you strange errors when you innocently
use a conflicting name. Also, a "reload(<module>)" is useless if
you've used "*".
- Gordon
Greg Ewing
>
> I'm a little confused about tuples vs. lists -- with the exception of the
> mutable/immutable thing, why would you pick one over the other? Is it a speed
> thing?
To a small extent, yes. In the current implementation, tuples
are a whisker more efficient than lists, because the whole
tuple object is contained in one heap block whereas
lists use two heap blocks. But I think you'd be straining
to notice any significant difference in running times
because of this.
> Is this just one of those personal style questions?
In the absence of a need to modify it in-place, it is
indeed a style issue. I tend to use tuples for fixed-size
structures containing perhaps heterogeneous items, and
lists for variable-sized homogeneous collections. Sort
of like the difference between structs and arrays in
C, or records and arrays in Pascal.
Sometimes the immutability of tuples can be an advantage -
if you have an object whose contents should not change,
making it a tuple ensures that you will find out if
you inadvertently try to modify it.
Another consideration is that you can, if you want,
write tuple construction and unpacking expressions
without surrounding parentheses. Whether you think
that is a good idea or not is of course another
stylistic decision!
--
Greg Ewing, Computer Science Dept, | The address below is not spam-
University of Canterbury, | protected, so as not to waste
Christchurch, New Zealand | the time of Guido van Rossum.
gr...@cosc.canterbury.ac.nz
Amit Patel
>Ah, the joys of newbies. Always asking stupid questions and unable to winkle
>out the trivia from the FAQs.
>
>mutable/immutable thing, why would you pick one over the other? Is it a speed
>thing?
>
>later on I might decide to add something smack in the middle of the thing and
>with a tuple, I'd have to write a few extra lines of code.
>
Here's another reason:
Later on *I* might decide to add something smack in the middle of *YOUR*
list and with a tuple, I couldn't do that.
So maybe... you want to use a tuple so that I can't go around messing
up your list!
Amit,
fondly remembering getting wizperms on POO because Joe used lists ;)
Michael P. Reilly
: I'm a little confused about tuples vs. lists -- with the exception of the
: mutable/immutable thing, why would you pick one over the other? Is it a speed
: thing?
Another reason to use tuples, which is directly from the fact that
tuples are immutable, is that tuples are hashable and can be used as
keys in a dictionaries:
for y in xrange(1024):
for x in xrange(1280):
points[(x, y)] = mandel(x, y)
Lists are mutable, and as a single construct, cannot be consistantly
hashable (i.e. always return the same hash value during the object's
lifetime).
Arcege