This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

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:52josh.rsetrecipients: + 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:52josh.rsetmessageid: <1504889752.44.0.212529648167.issue28638@psf.upfronthosting.co.za>
2017-09-08 16:55:52josh.rlinkissue28638 messages
2017-09-08 16:55:52josh.rcreate