[Python-Dev] namedtuple implementation grumble

[R. David Murray]

On Sat, 07 Jun 2014 10:50:16 -0400, Antoine Pitrou <antoine at python.org> wrote:
> 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.

For what it is worth, I found the discussion I was remembering:

    http://bugs.python.org/issue7796

And as someone pointed out down thread, the actual check is "inherits
from tuple and has a _fields attribute".

That gets you a duck type, which is generally what you want in Python.

--David