tuple.index()

Nick Maclaren nmm1 at cus.cam.ac.uk
Thu Dec 14 10:44:28 EST 2006


In article <elrqjl$j4s$1 at news.albasani.net>,
Georg Brandl <g.brandl-nospam at gmx.net> writes:
|> > 
|> > If lists are intended to be homogeneous, then they should be checked
|> > for that, and an exception raised when an attempt is to make them
|> > non-homogeneous.  At least as a Python checking option.
|> 
|> There you have the "consenting adults" philosophy again: You know what lists
|> are for, so you can use them for it. You can also use them for something else,
|> but in that case it's moot to complain about missing features.

One of the places where Cobol, Ada and Python are superior to C and Perl
is that they regard checking as a part of the language.

|> > If tuples are intended to be bags, then it makes no sense to allow
|> > them to be subscripted OR indexed.  Mathematically, 'x = a[i]' and
|> > 'i = a.index(x)' have dual properties - and are true duals if you
|> > include the constraint of no duplicate elements.
|> 
|> You're describing sets. Tuples are not sets. Sets are not indexable and have
|> unique elements.

Actually, I was describing bags - like sets, but with element multiplicity.
See http://en.wikipedia.org/wiki/Multiset

|> Indexing is the *vital* point of tuples. They are an ordered collection of
|> values, and you are supposed to know which data is found at which index.

Memo to self:  you really MUST remember NEVER to use reductio ad absurdum
on Usenet.

The point is that an index method makes sense on ANY data structure that
can be subscripted by an integer value but, for reasons that aren't at
all clear, is not defined for Python tuples.  There is no technical or
mathematical reason why it shouldn't be.


Regards,
Nick Maclaren.



More information about the Python-list mailing list