Message301700
| Author |
josh.r |
| Recipients |
JelleZijlstra, eric.smith, ethan smith, giampaolo.rodola, gvanrossum, josh.r, lazka, llllllllll, methane, ncoghlan, pitrou, rhettinger, serhiy.storchaka, vstinner, xiang.zhang |
| Date |
2017年09月08日.16:55:52 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1504889752.44.0.212529648167.issue28638@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Side-note: Some of the objections to a C level namedtuple implementation appear to be based on the maintenance hurdle, and other have noted that a structseq-based namedtuple might be an option. I have previously attempted to write a C replacement for namedtuple that dynamically created a StructSequence. I ran into a roadblock due to PyStructSequence_NewType (the API that exists to allow creation of runtime defined structseq) being completely broken (#28709).
If the struct sequence API was fixed, it should be a *lot* easier to implement a C level namedtuple with minimal work, removing (some) of the maintenance objections by simply reducing the amount of custom code involved.
The testnewtype.c code attached to #28709 (that demonstrates the bug) is 66 lines of code, and implements a basic C level namedtuple creator function (full support omitted for brevity, but aside from _source, most of it would be easy). I'd expect a finished version to be low three digit lines of custom code, a third or less of what the cnamedtuple project needed to write the whole thing from scratch. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2017年09月08日 16:55:52 | josh.r | set | recipients:
+ josh.r, gvanrossum, rhettinger, ncoghlan, pitrou, vstinner, eric.smith, giampaolo.rodola, methane, serhiy.storchaka, llllllllll, xiang.zhang, JelleZijlstra, lazka, ethan smith |
| 2017年09月08日 16:55:52 | josh.r | set | messageid: <1504889752.44.0.212529648167.issue28638@psf.upfronthosting.co.za> |
| 2017年09月08日 16:55:52 | josh.r | link | issue28638 messages |
| 2017年09月08日 16:55:52 | josh.r | create |
|