terminological obscurity

[Steve Holden]

Donn Cave wrote:

> In article <1l25b0damv22nmja2na0i3k55e0p3jsef4 at 4ax.com>,
>  Arthur <ajsiegel at optonline.com> wrote:
> ...
> 
>>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:

 >>> class bunch:
...   def __init__(self, **kw):
...     self.__dict__.update(kw)
...
 >>> a = bunch(my=0, word=1)
 >>> a.word
1
 >>>

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