tuples, index method, Python's design

Chris Mellon arkanes at gmail.com
Wed Apr 11 10:12:29 EDT 2007


On 4/11/07, Hamilton, William <whamil1 at entergy.com> wrote:
> > -----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.
>

So, when you have a) a third party module that you cannot change and
b) it shouldn't return a tuple but it does anyway and c) it's a big
enough tuple that is large enough that conversion to a list is
prohibitive, that's a "general" use case for tuple.index?

Has this supposedly general and common use case actually happened?



More information about the Python-list mailing list