terminological obscurity

[Shalabh Chaturvedi]

Grant Edwards wrote:

> In article <mailman.145.1085158045.6949.python-list at python.org>, Michael
> Chermside wrote:
> 
>>> All tuple methods are also list methods, and most list methods
>>> are also tuple methods; among those that are NOT also tuple
>>> methods, there are exactly two ('count' and 'index') that do
>>> not involve mutation. Is there any special reason why they
>>> AREN'T also tuple methods?
>> 
>> Yes. Both make sense only if you consider a tuple as a homogeneous
>> sequence of items, and that's not what Guido intended it to be
>> used for.
> 
> I'm sure I'm being dim, but I don't understand what homogeneity
> has to do with it.
> 
> For example, why shouldn't index() find an object in a
> non-homogeneous sequence? Either the object is in the sequence or
> it's not. If it is, there is an index that corresponds to it.
> 
> The relationship
> 
>  (a,b,c,d,e)[3] is d
> 
> is true regardless of the types of a,b,c and e.
> 
> I can maybe see why not supporting sort() or reduce() on a
> non-homogeneous sequence makes sense if one was of the opinion
> that it should be illegal to use a binary operator on two
> objects whose types differ, but I don't see why either count()
> or index() should have anything to do with homogeneity, since
> it pretty much has to be OK to use "is" or "==" on objects of
> differing types.
> 

I believe it is conceptual homogeneity and not type homogeneity that
characterises the difference between lists and tuples.

Consider use of tuples such as (hostname, port) or (firstname, lastname,
middleinitial) or (x_coordinate, y_coordinate). In all cases you *know*
what the first element means, what the second element means etc. It is
usually not useful to find a value since the different values mean
different things. You might rather do this something like - if host_port[1]
== 80:...

This might be the reason there is no index() on tuples - no convincing use
case.

--
Shalabh