Home Original page

[Python-Dev] namedtuple implementation grumble

Antoine Pitrou antoine at python.org
Sat Jun 7 16:50:16 CEST 2014 
Le 07/06/2014 09:25, R. David Murray a écrit :
> On Fri, 06 Jun 2014 19:50:57 +0100, Chris Withers <chris at simplistix.co.uk> wrote:
>> I've been trying to add support for explicit comparison of namedtuples
>> into testfixtures and hit a problem which lead me to read the source and
>> be sad.
>>
>> Rather than the mixin and class assembly in the function I expected to
>> find, I'm greeted by an exec of a string.
>>
>> 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 my case, that's somewhat irrelevant, I'm looking to store a comparer
>> in a registry that would get used for all namedtuples, but I have
>> nothing to key that off, there are no shared bases other than object and
>> tuple.
>>
>> I guess I could duck-type it based on the _fields attribute but that
>> feels implicit and fragile.
>>
>> What do you guys suggest?
>
> I seem to remember a previous discussion that concluded that duck typing
> based on _fields was the way to go.  (It's a public API, despite the _,
> due to name-tuple's attribute namespacing issues.)

There could be many third-party classes with a _fields member, so that 
sounds rather fragile.
There doesn't seem to be any technical reason barring the addition of a 
common base class for namedtuples.

Regards

Antoine.
More information about the Python-Dev mailing list