[Python-Dev] namedtuple implementation grumble

[Eric V. Smith]

On 6/8/2014 7:31 PM, Steven D'Aprano wrote:
> On Sun, Jun 08, 2014 at 03:13:55PM -0400, Eric V. Smith wrote:
>> 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:
> [...]
> 
> 
> I wonder how a hybrid approach would work? Use a dynamically-created 
> class, but then construct the __new__ method using exec and inject it 
> into the new class. As far as I can see, it's only __new__ that benefits 
> from the exec approach.
> 
> Anyone tried this yet? Is it worth an experiment?

I'm not sure what the benefit would be. Other than the ast manipulations
for __new__, the rest of the non-exec code is easy to understand.

Eric.