Named tuples

[Carlos Ribeiro]

On Wed, 17 Nov 2004 23:56:31 +0100, Alex Martelli <aleaxit at yahoo.com> wrote:
> Carlos Ribeiro <carribeiro at gmail.com> wrote:
> 
> > But perhaps we could have something like "named tuples"; immutable
> > objects, like tuples, with the property that a unique name can be
> > associated to every item.
> 
> Of course we should -- I've lost count of how many recipes in the
> cookbook I've merged that were implementing that idea in umpteen ways,
> not counting several other ideas that only flew by in this NG.  Since
> standard modules time, os (for stat), resource (dunno if any others),
> started returning this kind of supertuples, their convenience has been
> obvious to all.  I do believe they SHOULD _be_ tuples (that matters when
> they're the only RHS argument of a % formatting operator) and it should
> also be easy to get from them a name->value mapping (for % formatting
> with named-items format style, and the like).  Definitely PEP time...
> who's gonna carry the torch?

*After* I posted that message, I *did* some research (wrong order, I
know). And you're right, the situation now is pretty much like
Tanenbaum's famous quote: "the nice thing about standards is that
there are so many of them to choose from".

I am tempted to start writing this PEP. I think that I have a pretty
good idea about what do I want (which by itself isn't worth very
much). Anyway, it's a starting point:

1. Do not change the syntax. This leaves out some of the fancy
proposals, but greatly improves the acceptance chances.

2. Named tuples should, for all practical purposes, be an extension of
standard tuples.

3. Conventional access returns a tuple. __getitem__ works as in a
tuple, and the object itself is represented (by repr() and str()) as a
tuple.

4. Named attribute access is supported by __getattr__. Names are
looked up on the magic __names__ attribute of the tuple.

5. On slicing, a named tuple should return another named tuple. This
means that the __names__ tuple has to be sliced also.

6. Although useful, a new named tuple *cannot* be built directly from
a dict, as in this example:

tuple({'a':1, 'b':2})

...because the dict isn't ordered, and there is no way to guarantee
that the tuple would be constructed in the correct order. This will
only be possible if the dict stores the ordering information (btw, the
'correct' order is the definition order; it's the only one that can't
be inferred later at runtime, and alphabetical ordering can be always
obtained by a simple sort).

(However, *if* ordered dicts ever make it into the language, then a
conversion between 'named tuples' and 'ordered dicts' would become
natural -- think about it as an 'adaptation' :-)

7. Now for the controversial stuff. NamedTuples can be implemented as
a regular class -- there are many recipes to look at and choose from.
However, I think that is possible to implement named attribute access
as an "improvement" of regular sequence types, with no syntax changes.

The idea is that any tuple could be turned into a named tuple by
assigning a sequence of names to its __names__ magic attribute. If the
attribute isn't assigned (as it's the case with plain tuples), then
the named attribute is disabled. BTW, adding names to an unnamed tuple
*does not* violates the immutability of the tuple.

The usage would be as follows:

    time = now()
    time.__names__ = ('hour', 'minute', 'second')
    print time.hour

The reasoning behind this proposal is as follows:

7.1. It's fully backwards-compatible.

7.2. It allow for easy annotation of existing tuples.

7.3. It allows for internal optimization. By using an internal mapping
directly wired into the sequence, it is possible to hide the mapping
mechanism, and also to make it work faster. This also adds a safety
layer, and helps to avoid direct 'peeking' at the internal mapping
structure that will be exposed by a native Python implementation.

The *biggest* problem of this proposal is that it's MUCH more complex
-- orders of magnitude, perhaps -- and also, that it may present
problems for others implementations besides CPython. Anyway, it's
something that I think deserves discussion.


-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carribeiro at gmail.com
mail: carribeiro at yahoo.com