terminological obscurity

[Donn Cave]

In article <b9Gtc.213$eP.42 at lakeread01>,
 Steve Holden <sholden at holdenweb.com> wrote:
...
> The important thrust of this apparently endless discussion is to 
> highlight the possible need for some way *other than indexing* to get 
> information out of a tuple. Really, most places where tuples are used, a 
> programmer might find it more convenient to extract the elements as 
> attributes - by name rather than position - hence the changes to the 
> os.path.stat() return value in version 2.2. People got tired of 
> accessing the individual values by using the appropriate index.
> 
> I'm guessing (though in this forum I am likely to be proved wrong at 
> some length) that most uses of tuples could senibly be replaced by 
> simple "bunch"-type objects in the Alex Martelli sense:
> 
>  >>> class bunch:
> ...   def __init__(self, **kw):
> ...     self.__dict__.update(kw)
> ...
>  >>> a = bunch(my=0, word=1)
>  >>> a.word
> 1
>  >>>
> 
> However it's a bit late to start insisting on this usage when the tuple 
> has been embedded in the language so long.

Sure, the stat and tm structs are a good example of what they're
a good example of.  Once a tuple has more than a handful of
elements, you're past the cognitive limit for really workable
tuples.

For tuples of more reasonable size, I think most of us prefer to
unpack.   Even if I have to check on the order first, I'd rather
write
      client, client_addr = service.accept()
      for k, v in q.items:

etc.  That's why the tuple has been embedded in the language so
long without sprouting these features, because it works well when
used well.

   Donn Cave, donn at u.washington.edu