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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
