terminological obscurity

[Terry Reedy]

"John Roth" <newsgroups at jhrothjr.com> wrote in message
news:10asqll7hiq9l48 at news.supernews.com...
> This is one of the longstanding issues. Guido intended lists
> for conceptually homogeneous cases: that is, part of a list
> is conceptually similar to the entire list.
>
> Tuples are intended for places where you want to simply
> gather up a bunch of objects into one object for convenience
> in passing them around. Assume, for example, that I've got
> a tuple that includes a name, address, postal code, telephone
> number, part number and order quantity. Half of that tuple
> is not conceptually the same as the entire tuple. That's what
> is meant by inhomogenaity.

The argument against tuple.count() and tuple.index() could also be used
against tuple slicing, but I won't say that too loudly.

> There are a number of places where this gets sticky,
> and other people regard other properties as more important.

For me, mutability is pragmatically the most important.  I would prefer
that .count, .index, and .rindex were identical across sequences.

> It is, however, Guido's language. He's the Benevolant Dictator
> for Life, so his intention is the official intention.

But anyone is free to implement private intentions with count and index
functions.  The itertools make it easy to write efficient and more general
functions which count or locate items produced by *any* iterable, not just
lists, that match any criterion, not just equality to a particular value.
So the addition of two specialized methods to one type is not currently an
issue to me.

Terry J. Reedy