tuple.index()

[Nick Maclaren]

In article <1166118142.144177.78790 at l12g2000cwl.googlegroups.com>,
"Carl Banks" <pavlovevidence at gmail.com> writes:
|> Glenn Hutchings wrote:
|> > Simon Brunning wrote:
|> > > It's because, philosophically, a Python tuple isn't just a read-only list.
|> >
|> > But there are situations where you might want to treat it as a
|> > read-only list.  E.g., an argument to a function, so that you can
|> > guarantee the function won't modify it.
|> 
|> Seems to me a misplaced fear.  Do you take steps to also protect other
|> mutable arguments (dicts, class instances, etc.)?  If not, there should
|> be no reason why you should protect lists that way either.  If so, you
|> could do a similar thing for lists as well.

Well, in an ideal language, yes.  And, yes, that is the correct solution.
If I were a designing a language, mutability would be an orthogonal
property to type.  It isn't a misplaced fear, but the extra protection
provided by doing that only for tuples is like locking one door out of
ten to deter burglars - good practice, if there is no downside, but not
worth putting much effort into.

And the 'misplaced fear' assertion is equally applicable to the misuse
of tuples - but that viewpoint is clearly heretical :-)

|> For the record, I don't agree with tuple's absent count and index
|> methods either, but for other reasons.  It's a minor thing.  I deal
|> with it.

Indeed.  The code to sort out the problem was trivial.  I was curious
as to the reason, since there was no technical or mathematical one, and
seem to have accidentally committed one of Python's Seven Unforgiveable
Heresies, to have lost my soul irredeemably, and to be in danger of
being burnt at the stake.

Ah, well.

[ Incidentally, my use was in argument decoding, where the Python layer
holds the arguments as strings, and I need to pass them as an index to C
(so they DO form a respectable tuple even in Guido's sense, being fixed
in number and value and just happening to be homogeneous). ]



Regards,
Nick Maclaren.