terminological obscurity

Donn Cave donn at u.washington.edu
Fri May 21 16:45:22 EDT 2004


In article <40ae3ebe$0$17254$a1866201 at newsreader.visi.com>,
 Grant Edwards <grante at visi.com> 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.

For example,
  tm = time.localtime(time.time())
  i = tm.index(5)

What would that mean?

It's absurd to search for the location of a value in a tuple,
because the values don't have any meaning independent of their
location.

That sort of is a homogeneity issue, but it's confusing because
here we don't mean each element is similar to the others - in
fact that does often hold for tuples - but rather that the sequence
itself is similar from one place to another.  Which is true for
lists - normally there's no real meaning attached to location -
but not for tuples, where normally location determines meaning.

   Donn Cave, donn at u.washington.edu



More information about the Python-list mailing list