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). Regards, Jason -----Original Message----- From: Calvin Spealman [mailto:[EMAIL PROTECTED] Sent: Friday, 13 June, 2008 12:17 To: Jason R. Coombs Cc: python-list@python.org 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 :-)
smime.p7s
Description: S/MIME cryptographic signature
-- http://mail.python.org/mailman/listinfo/python-list
