Named tuples and projection

Giuseppe Ottaviano giuott at gmail.com
Fri Jun 20 10:38:37 CEST 2008


I found the namedtuple very convenient for rapid prototyping code, for  
functions that have to return a number of results that could grow as  
the code evolves. They are more elegant than dicts, and I don't have  
to create a new explicit class. Unfortunately in this situation they  
lose the convenience of tuple unpacking: changing tuple's parameters  
would break other functions unpacking the result.
One solution, with 3.0 syntax, would be unpacking only the used  
parameters, using always a *rest
a, b, *rest = f()
so that if the tuple grows, the code keeps working.
However I find this confusing (and not avaliable in python 2.5).
I don't know if similar solutions have been proposed, I came up with  
this one:

Add a method "project" that given a string of arguments (in a similar  
fashion as namedtuple construction) returns a tuple with only that  
items. I monkeypatched the namedtuple recipe as a proof of concept,  
replace "return result" with these lines:

     def _project(self, fields):
	return tuple(getattr(self, field) for field in fields.split())
     def _getitem(self, item):
	if isinstance(item, str):
	    return self.project(item)
	return super(result, self).__getitem__(item)

     result.project = _project
     result.__getitem__ = _getitem

     return result

This is the result:

In [2]: X = namedtuple('X', 'a b c d')

In [3]: x = X(1, 2, 3, 4)

In [4]: a, c = x.project('a c')

In [5]: a, c
Out[5]: (1, 3)

In [6]: a, d = x['a d']

In [7]: a, d
Out[7]: (1, 4)

In [8]: x[2]
Out[8]: 3

I implemented also __getitem__ just to show another possible syntax  
(maybe a bit ugly). project may be not a self-evident name, probably  
something like "select" (for SQL addicts) would be more appropriate.
Other possible solutions?

Thanks,
Giuseppe



More information about the Python-list mailing list