On Fri, Apr 26, 2013 at 8:29 AM, Barry Warsaw <ba...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
