[Python-Dev] namedtuple implementation grumble (original) (raw)

Eric V. Smith eric at trueblade.com
Sun Jun 8 21:13:55 CEST 2014

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:

Eric.

More information about the Python-Dev mailing list