Movatterモバイル変換


[0]ホーム

URL:


[Python-Dev] namedtuple implementation grumble

Paul Sokolovskypmiscml at gmail.com
Sat Jun 7 22:00:15 CEST 2014


Hello,On Sat, 07 Jun 2014 12:42:32 -0700Glenn 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 forboth "tuple" base class and "_fields" member will identify it with~same probability as a check for special base type (because it's fairto say that if someone *both* subclassed a builtin type and add _fieldsmember, then they wanted it to be treated as namedtuple).[]-- Best regards, Paul                          mailto:pmiscml at gmail.com


More information about the Python-Devmailing list

[8]ページ先頭

©2009-2025 Movatter.jp