> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:python- > [EMAIL PROTECTED] On Behalf Of Steven D'Aprano > Sent: Wednesday, April 11, 2007 7:49 AM > To: python-list@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 [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
