On May 06, 2013, at 02:51 PM, Nick Coghlan wrote: >Enums are the same - they carve out a subtree in the type hierarchy >that *doesn't* behave the same as the standard tree anchored directly >on type. This *is* going to cause conflicts with meta-tools that only >handle ordinary types - the trick is that the cause of the problem (a >custom metaclass) is also the solution (a custom metaclass derived >from enum.enum_type).
Agreed. When the time is right, I think we should consider implementation details that allow for useful flexibility. An example would be the prohibition on extension through subclassing. I'm perfectly willing to accept that as the standard behavior on stdlib Enums, but I'd like to be able to override this with my own custom metaclass subclass. I think it could be done quite easily with the right refactoring of the implementation, although there would be some discussion around what is blessed private API and what is YOYO[1] API. -Barry [1] You're own your own. _______________________________________________ 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
