[Python-Dev] PEP 435 -- Adding an Enum type to the Python standard library

Nick Coghlan ncoghlan at gmail.com
Fri Apr 26 04:13:12 CEST 2013


On Fri, Apr 26, 2013 at 8:29 AM, Barry Warsaw <barry at python.org> wrote:
> On Apr 25, 2013, at 03:19 PM, Guido van Rossum wrote:
>
>>Clearly this is a trick question. :-)
>
> A bit, yes. :)
>
>>I was told when this was brought up previously (a week ago?) that it
>>would be simple to make it truly the same class.
>
> It didn't sound simple to me, but I haven't seen any actual code yet.

I'm the one who said I didn't see any obvious barriers to the merger,
but I've realised there is one, and it's similar to one namedtuple
struggles with: how to handle method definitions.

With the current flufl.enum design, if you want to give instances of a
particular enum additional behaviour, you can use a custom item type
and add the methods there. Simple and relatively obvious.

With a merged design, it becomes *really* hard to give the instances
custom behaviour, because the metaclass will somehow have to
differentiate between namespace entries that are intended to be
callables, and those which are intended to be instances of the enum.
This is not an easy problem to solve.

So, while I was initially in the "merge them" camp, I'm back to
thinking the core architecture of flufl.enum is correct, but there may
be some API adjustment to do, such as:

1. Lose the __getitem__ on the metaclass, and replace that with __call__
2. Ensure that isinstance(MyEnum.item, MyEnum) returns True (even
though it isn't really)
3. Inspired by namedtuple, move the current Enum constructor
functionality to an Enum._make() API (implemented either as a class
method in Enum or as an ordinary method on the metaclass)

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list