[Python-ideas] PEP for enum library type?

Antoine Pitrou solipsis at pitrou.net
Thu Feb 14 12:16:02 CET 2013


Le Thu, 14 Feb 2013 20:40:37 +1000,
Nick Coghlan <ncoghlan at 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.





More information about the Python-ideas mailing list