[Python-Dev] namedtuple implementation grumble (original) (raw)

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