Donn said:
Well for one, before new style classes, it was easier to think of an
"instance" as in some sense a pseudo data type. Instances of
different classes - even with no hierarchical relationship - were more
conceptually homogenous.
But with everything subclassable, 2 different classes, each derived
from object, are conceptually distinguished more similarly to the way
in which a str and int are distinguished.
Really makes no difference at all - not just insignificant,
really _no_ difference. A truly heterogeneous sequence may
be full of references to the _same_ object (e.g., (1, 1, 1)),
and a truly homogeneous sequence may have objects as different
as None and a module. It's not about properties of the objects,
considered in isolation.
Absolutely. See below.
GvR> I always think of the type of a list as "list of T" while I
GvR> think of a tuple's type as "tuple of length N with items of
GvR> types T1, T2, T3, ..., TN". So [1, 2] and [1, 2, 3] are both
GvR> "list of int" (and "list of Number" and "list of Object", of
GvR> course) while ("hello", 42) is a "2-tuple with items str and
GvR> int" and (42, "hello", 3.14) is a "3-tuple with items int,
GvR> str, float".
He sort of stacks the cards by making his tuples of hetereogenous
type, and his list easily described as a list of T. And thereby
sidesteps all the ambiguities inherent in the ten word edict. Except
that at the Object level, we are at lists of Objects and tuples of
Objects. It detracts little from the point of the above quote, but
this quote then becomes substantially weaker as support for his 10
worder.
While Arthur is possibly correct in the sense that "I can't argue with
that", he's also correct in the sense that "English and Python are both
languages".
Guess he may have overestimated his audience.
More likely he was speaking to a specific question, and is now being
taken out of context.
If you're interested in the history of this matter, it may
help to know that Guido did not invent the tuple. It has
been around in computer programming languages since Lisp.
You can actually find precisely parallel descriptions of
the concept in that context, down to the unnecessary use
of different data types to emphasize the heterogeneity.
Furthermore, all such implementations are probably based on the tuple as
used by mathematicians since God was a lad. A tuple is an ORDERED
collection of items, not necessarily of the same type.
The important thing about a mathematical tuple is that it is constructed
so that the position of an element in the tuple signifies its purpose.
The important thrust of this apparently endless discussion is to
highlight the possible need for some way *other than indexing* to get
information out of a tuple. Really, most places where tuples are used, a
programmer might find it more convenient to extract the elements as
attributes - by name rather than position - hence the changes to the
os.path.stat() return value in version 2.2. People got tired of
accessing the individual values by using the appropriate index.
I'm guessing (though in this forum I am likely to be proved wrong at
some length) that most uses of tuples could senibly be replaced by
simple "bunch"-type objects in the Alex Martelli sense:
.... def __init__(self, **kw):
.... self.__dict__.update(kw)
....
However it's a bit late to start insisting on this usage when the tuple
has been embedded in the language so long.
The thing that ticks me off is when I come across a module that INSISTS
I provide a tuple, when really a list would be perfectly adequate. This
often happens in database munging applications: retrieving data yields a
tuple (perfectly appropriate, as each column is potentially of its own
type). To add further information I have to convert this tuple to a list
and modify it. Can I write this list out using the DBAPI interface?
Well, usually I first have to convert it to a tuple, because most
database modules require a tuple. Frankly I wish they'd be a bit less
picky, and do the conversion themselves if they must.
Obviously it would also be helpful if DB values were accessible by
attribute name. The problem wtih that is one can't always guarantee that
SQL will name things in Python-compatible ways. For some reason, it
seems that database deigners (though probably the ones who exclusively
use GUIs) have a penchant for weird characters like spaces and pound
signs in their column names. Don't get me started ...
Lisp and its relatives have both a tuple and a list type,
but the list is a `real list', not a 1-dimension array as
in Python but a recursive data structure. In Python, this
data structure can be represented using a tuple:
t = (0, None)
t = (1, t)
t = (2, t)
...
def print_list(tail):
value, tail = tail
if tail:
print_list(tail)
print value
Guido's "mistake" is that unification of all these sequence
types leaves the distinctions less obvious.
While it's interesting for us all to discuss how many objects can dance
on the head of a pin, however, it probably won't be profitable. The
bottom line, for pragmatists, is that you can do 'most anything with a
list that you can with a tuple EXCEPT use it as a dictionary key.
Just as some people will do integer arithmetic using floating point
numbers, so some people will use lists where tuples might be more
appropriate.
Just as (sometimes) floating-point's inaccuracies will bite the careless
user in the ass, so (sometimes) will inappropriate use of lists (though
much less frequently).
regards
Steve
