[Python-Dev] namedtuple implementation grumble
Paul Sokolovsky
pmiscml at gmail.com
Sat Jun 7 22:00:15 CEST 2014
Hello,
On Sat, 07 Jun 2014 12:42:32 -0700
Glenn Linderman <v+python at g.nevcal.com> wrote:
> On 6/7/2014 7:50 AM, Antoine Pitrou 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 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.
>
> A common base class sounds like a good idea, to me, at a minimum, to
> help identify all the namedtuple derivatives.
I'm perplexed - isn't "tuple" such common base class? And checking for
both "tuple" base class and "_fields" member will identify it with
~same probability as a check for special base type (because it's fair
to say that if someone *both* subclassed a builtin type and add _fields
member, then they wanted it to be treated as namedtuple).
[]
--
Best regards,
Paul mailto:pmiscml at gmail.com
More information about the Python-Dev
mailing list