tuples, index method, Python's design

[Hamilton, William]

> -----Original Message-----
> From: python-list-bounces+whamil1=entergy.com at python.org
[mailto:python-
> list-bounces+whamil1=entergy.com at python.org] On Behalf Of Steven
D'Aprano
> Sent: Wednesday, April 11, 2007 7:49 AM
> To: python-list at python.org
> Subject: Re: tuples, index method, Python's design
> 
> (There is one other option: you care that 32 is somewhere in the
tuple,
> but you don't care where. That's when you use the "in" operator.)
> 
> Anyway, that was the original design. When you see tuple, think
struct. If
> you have a struct, it doesn't make a whole lot of sense to ask "which
> field contains 32?", and so according to this intended usage, giving
> tuples index and count methods would be a Bad Idea: it just makes
extra
> work for the Python Dev team, for no benefit.
> 
> Personally, I think that tuples do double-duty as *both* immutable
lists
> and structs/records. So even though index and count methods don't make
> sense for a struct, it does make sense for an immutable list, and I
for
> one would not object to seeing tuples grow those two methods. 


>From another function, you receive a tuple of data that it extracted
from a stream.  Within that tuple is a marker that indicates where the
head of the incoming stream's data structure is.  You need to find the
marker and scan from that location on to sync your local data structure
to the incoming stream's data.  

Should the external function provide the stream data in a list rather
than a tuple?  Probably, but someone else wrote the function so that's
out of your control.  Can you cast the tuple to a list?  Sure, but for a
large tuple that's potentially a large speed and memory hit.

That probably the biggest general use case for tuple.index().  A
third-party module returns a tuple in which you need to find a piece of
data.


---
-Bill Hamilton
whamil1 at entergy.com