[Tutor] Creating a complex python object
my.mailing.lists at noos.fr
Sat Aug 14 01:16:05 CEST 2004
Bob Gailer wrote:
> At 12:13 PM 8/13/2004, Jeff Shannon wrote:
>> Chad Crabtree wrote:
>>> >In the mean time I'll keep lurking on this list, there's still a
>>> lot to python that baffles me (like just what is the difference
>>> between a
>>> tuple and a list? :-) ).
>>> I thought I would answer the tuple list thing. I did not understand
>>> why have tuple's until I learned that tuples being immutable are faster
>>> and easier on memory.
>> Actually, speed and memory considerations are only incidental.
>> One of the most important reasons that Python has both (mutable)
>> lists and (immutable) tuples is because dictionaries don't work with
>> mutable keys. If you stuck something into a dictionary that was
>> keyed on a list, and then that list changed, you'd never be able to
>> get that dictionary value back. But dictionaries are an important
>> part of Python (many internal data structures are effectively
>> dictionaries, among other things), and it's very valuable to be able
>> to use a group of items as keys -- for example, a dictionary showing
>> grid locations is much cleaner if you can key off of (x, y), rather
>> than having a dictionary at x that has another dictionary that's
>> keyed off of y.
>> So, dictionaries are the reason that we have tuples. But once we
>> *have* them, they tend to grow other differences...
>> The common usage, now, is that lists usually contain a sequence of
>> similar things, whereas tuples are usually more like a record,
>> grouping together dissimilar things that are conceptually related.
>> Thus, for example, in the date-time tuple returned by time.gmtime()
>> each position within the tuple represents a different thing. In
>> contrast, each position in a list represents a different instance,
>> but all of the contents are the same type of thing. This distinction
>> is just convention, of course, and there's nothing forcing you to
>> follow it, but you'll find that just about every standard library
>> module (and most other code, as well) will follow this guideline.
> Darn - and just today I created a mechanism using a list in which the
> 1st element is a string and the rest integer. Sigh.
I've seen the homogeneous vs heterogeneous description of lists and
tuples, but pure convention doesn't seem to be a very good argument for
it. There must be a good practical reason that it's settled in that form
- why didn't it settle in the opposite fashion; lists=heterogeneous,
tuples=homogeneous? Is it the immutability of the tuple, or the fact you
can't use a list as a key that's pushed it in that direction, or was it
really as simple as one guy in the early days saying 'I prefer this
More information about the Tutor