[Guido]
... I have a feeling that introducing optional static typing would help here, because it clarifies the concept. For example, these two have the same type, [int]: (the length is part of the value)
[3, 100] [5, 6, 7]
On the other hand, these two have different types:
(3, 100) # (int, int) (5, 6, 7) # (int, int, int)
If we start mixing types, we may get
[3, "wow"] # [any]; or perhaps [int|str] (3, "wow") # (int, str)
Very much the same applies to functional languages, except (usually) even more so. For example, Haskell has both lists and tuples, but lists are homogenous (and the type system has no union types, at least not of the int|str form -- the list [3, "wow"] can't be expressed (although the tuple form can be): ? [3, "wow"] ERROR: [Char] is not an instance of class "Num" ? (a Haskell string is a list of Char, which is what [Char] means)). At heart, tuples are for Cartesian products of a fixed number of possibly differing types, while lists are for arbitrary-length sequences of a single type. This is good style even in Python! (Think about it: when you see a newbie post on c.l.py that violates your Python intuition wrt list or tuple use, in my experience it almost always violates one of those (hitherto never expressed <wink>) guidelines.) That lists are allowed to be heterogenous should really be considered an advanced feature; ditto list operations (like indexing) on tuples. BTW, despite the recent unpleasantness with the TeachScheme! folks, there's a lot to be learned from DrScheme, part of which is the notion of language "levels": the IDE can be set to restrict the newbie to various (nested) subsets of the full language, so that new learners are shielded from the hairier stuff until their confidence builds. metaclasses-are-a-good-candidate<wink>-ly y'rs - tim