Author josh.r
Recipients Ethan Smith, Jelle Zijlstra, eric.smith, giampaolo.rodola, gvanrossum, inada.naoki, josh.r, lazka, llllllllll, 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, inada.naoki, serhiy.storchaka, llllllllll, xiang.zhang, Jelle Zijlstra, 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