Le Thu, 14 Feb 2013 20:40:37 +1000, Nick Coghlan <ncoghlan@gmail.com> a écrit :
collections.namedtuple is the normative example here, and while the repetition of the class name is still annoying, that's a minor irritation compared to completely violating everyone's expectations of normal class behaviour.
I find it slightly amusing that you're complaining about a violation one of your latest PEPs is trying to make easier to make. But, still, you are not convincing me that namedtuple is normative in any way. The fact that many people would prefer a class-based declarative syntax for namedtuple is proof. By the way, not only is the repetition of the class name annoying, but it also makes subclassing more annoying too. Most of my uses of namedtuple imply subclassing, because I add some behaviour (for example additional constructors or serializers). So, compare: _BaseProtocolItem = namedtuple('_BaseProtocolItem', ('serial_no', 'command')) class ProtocolItem(_BaseProtocolItem): # snip custom methods To the hypothetical: class ProtocolItem(NamedTuple): __fields__ = ('serial_no', 'command') # snip custom methods And you understand why the namedtuple() factory function is really an inferior solution with too much typing.
In which case, they should stop discussing them on python-ideas. flufl.enum is a perfectly fine example of normal Pythonic class design, with similar examples already in the standard library. The approaches being thrown around on this list lately are very cool from a technical point of view, and impressive illustrations of what Python's metaclass machinery can do for you, but they're also completely unintuitive black magic (including "x = ..." having any result other than "x is Ellipsis").
You're still ignoring the less-magic solutions such as: class Errno(Enum): __enumvalues__ = ('EBADF', 'ENOENT',) Regards Antoine.