On 6/7/2014 10:46 AM, Nick Coghlan wrote: > On 7 June 2014 04:50, Chris Withers <ch...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
