namedtuple suggestions

Jason R. Coombs jaraco at
Fri Jun 13 18:28:45 CEST 2008

I also agree with your point on concatting.  I used that syntax because it
seemed more clear, given the already awkward syntax.

And while the original motivation of namedtuple might be to avoid having to
make a class or subclass, subclasses have already emerged even within the
standard library (see lib/urlparse for a prime example of extending the
namedtuple class).


-----Original Message-----
From: Calvin Spealman [mailto:ironfroggy at] 
Sent: Friday, 13 June, 2008 12:17
To: Jason R. Coombs
Cc: python-list at
Subject: Re: namedtuple suggestions

On Jun 13, 2008, at 11:17 AM, Jason R. Coombs wrote:

> I see a new function in (python 2.6) lib/collections called
> namedtuple.  This is a great function.  I can see many places in my
> code where this will be immensely useful.
> I have a couple of suggestions.
> My first suggestion is to use self.__class__.__name__ instead of the
> hard-coded typename in __repr__, so that subclasses don't have to
> override these methods just to use the correct name.
>         def __repr__(self):
>             return self.__class__.__name__ + '(%(reprtxt)s)' %% self
> \n

I feel like a large point of NamedTuple is for those cases where you  
need a small object with some attributes _without_ creating a  
subclass. Useful for mocks, for example, or when you need to trick a  
function into dealing with a quick proxy or stub. If a large point is  
not needing to create a class but instead creating a cheap object,  
should it be a good idea to then subclass the very thing that was  
intended to help you avoid creating a class in the first place? What  
do you gain subclassing it?

However, I always think a repr reflecting a type name should reflect  
the correct type, so I'm not disagreeing on that point. But, just  
don't use concating :-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6580 bytes
Desc: not available
URL: <>

More information about the Python-list mailing list