> 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, 

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:  

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:  

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.

Python-Dev mailing list

Reply via email to