[Python-Dev] Suggestions for Improvements to namedtuple

[Raymond Hettinger]

> for efficiency I would prefer to avoid using * to break
> up the sequences generated directly by the database interface.

There are some use cases that would be better served by an alternate design and others that are better served by the current design.  For example, it would really suck to have to type-out an an enclosing set of parenthesis to build a named tuple explicitly:  opt = StockOption((daysleft/360., strike/100.0, bool(putcall))).

The alternate signature was discussed and rejected previously. See some of the details on previous python-dev posting and in the ASPN recipe discussion: at some length in the ASPN recipe:  http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/500261

FWIW, the current design does work efficiently with your use case if you use itertools to apply the named tuple cast to large record sets.  See the example in the docs:  http://docs.python.org/dev/library/collections.html#named-tuple-factory-function-for-tuples-with-named-fields

Also, fwiw, I've had good success using this starmap() approach in some performance critcal applications.

Almost every class in Python could be subjected to the same discussion.  Why doesn't every class and function accept a tuple of args instead of separate, serial arguments.  The * operator and starmap() function were provided specifically to address the inter-conversion between the two approaches.


>  It would be nice to be able to have default values 

This came-up before, but I'll take another look at it this weekend.  If it significantly complicates the API or impacts performance, then it is a non-starter; otherwise, I'll  put together an implementation and float it on ASPN for comments.

> In my opinion __replace__ should be able to replace multiple fields.

This may be do-able.  Will take a look at it.  The current design is easily extended for this without impacting performance.  The question is whether is makes sense in normal applications to do multiple replacements at once.  FWIW, the str.replace function only has one target/replacement pair.

> To me, exec is a last resort

It was a last resort here also.  Earlier versions of the recipe used type() but they were less flexible, slower, had crummy error reporting, and were much less clear.  The exec version has the advantage of being able to print-out the template so you can see *exactly* what it is doing.  I ended-up putting in a lot f field validation to prevent injection attacks (they are also they to provide more actionable error messages).

> crucial stuff like __fields__ and __signature__ fully
> read-write.  It feels like those should be read-only properties.
> ... On the other hand, I'm a recovering Java programmer,

Welcome to the Python world of consenting adults.  These fields could be made read-only but that is just a matter of taste.  Looking through the standard library, you'll see making attributes read-only is not the typical practice.  If  users demand it, I don't see a problem with it, but until then, I don't see a reason to unnecessarily complicate and slow-down the code.

FWIW, you're welcome to email me directly.  I've been getting tons of user feedback and have already incorporated the better suggestions.  Also, the recipe itself is a combination of the best of prior attempts.  Unfortunately, each of several commenters revisit everything from scratch and propose their own complete rewrites that ignore the requests and commments of all those who preceded them.  Fortunately, we're homing in on a darned good tool.


Raymond