[Tutor] Creating a complex python object

[nik]

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 
convention'?