[Python-Dev] namedtuple implementation grumble

[Eric V. Smith]

On 6/7/2014 10:46 AM, Nick Coghlan wrote:
> On 7 June 2014 04:50, Chris Withers <chris at simplistix.co.uk> wrote:
>> Curious as to what lead to that implementation approach? What does it buy
>> that couldn't have been obtained by a mixin providing the functionality?
> 
> In principle, you could get the equivalent of collections.namedtuple
> through dynamically constructed classes. In practice, that's actually
> easier said than done, so the fact the current implementation works
> fine for almost all purposes acts as a powerful disincentive to
> rewriting it. The current implementation is also *really* easy to
> understand, while writing out the dynamic type creation explicitly
> would likely require much deeper knowledge of the type machinery to
> follow.

As proof that it's harder to understand, here's an example of that
dynamically creating functions and types:

https://pypi.python.org/pypi/namedlist

https://bitbucket.org/ericvsmith/namedlist/src/163d0d05e94f9cc0af8e269015b9ac3bf9a83826/namedlist.py?at=default#cl-155

It uses the ast module to build an __init__ (or __new__) function
dynamically, without exec. Then it creates a type using that function to
initialize the new type. namedlist.namedtuple passes all
collections.namedtuple tests, except for those using the _source
attribute (of course).

namedlist.namedlist and namedlist.namedtuple both support a clunky
interface to specify default values for member fields.

The reasons I didn't use the collections.namedtuple exec-based approach are:
- specify default values to __init__ or __new__ became very complex
- 2.x and 3.x support is harder with exec

Eric.