In article <[EMAIL PROTECTED]>, "Carl Banks" <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
