[issue17954] Support creation of extensible enums through metaclass subclassing
Changes by Barry A. Warsaw ba...@python.org: -- nosy: +barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17954] Support creation of extensible enums through metaclass subclassing
Nick Coghlan added the comment: I don't think that would be wise - there's currently other logic in _get_mixins that subclasses would then have to duplicate. I was thinking more of an allow_subclass() API that subtypes could override to always return True. EnumMeta would then just factor the relevant piece of _get_mixins out into the default allow_subclass implementation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17954] Support creation of extensible enums through metaclass subclassing
Nick Coghlan added the comment: I elaborated on this point in http://python-notes.boredomandlaziness.org/en/latest/python3/enum_creation.html#support-for-alternate-declaration-syntaxes However, I'm now wondering if the problem is simply that the no extension of enums rule is more restrictive than it needs to be. If you *don't define any new methods*, then there's no problem with extending an enumeration - it's only the combination of extension and adding extra behaviour which is incoherent. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17954] Support creation of extensible enums through metaclass subclassing
Ethan Furman added the comment: Make it simpler: class EnumMeta(): allow_subclass = False class MyEnumMeta(EnumMeta): allow_subclass = True -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17954] Support creation of extensible enums through metaclass subclassing
Nick Coghlan added the comment: Simply removing the restriction isn't actually appropriate, as the variants that allow addition of new members should *not* allow addition of new descriptors. That's why I'm wondering if the current subclassing restriction is wrong: if you subclass an Enum derivative that already has defined members, then adding new members is OK, but adding new behaviour is not. If you subclass an Enum derivative with no members, then adding either members or behaviours is fine. If we relaxed the no subclassing rule to no new non-members, then this Enums would be natively extensible and this customisation hack wouldn't be necessary at all. We have plenty of time before 3.4 - let's get the existing implementation in before worrying further about this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17954] Support creation of extensible enums through metaclass subclassing
Ethan Furman added the comment: Not trying to push, but if I don't write it down now, I'll forget later. ;) What does adding new members gain us? If I have a func xyz() that's expecting a Color, a MoreColor will work sometimes and blow up other times. Or are you saying that we may have a function mno() that takes a Color or a MoreColor? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17954] Support creation of extensible enums through metaclass subclassing
Nick Coghlan added the comment: Ah, you're right, I forgot that was the other reason for disallowing extensions through subclassing. To get extensions to work right, you need to flip it around so that isinstance(Color.red, MoreColor) is True, while isinstance(MoreColor.magenta, Color) is False. -- dependencies: -Code, test, and doc review for PEP-0435 Enum resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17954] Support creation of extensible enums through metaclass subclassing
New submission from Nick Coghlan: Guido chose to follow Java in enforcing the invariant Enum members are instances of that Enum for PEP 435 (i.e. assert (all(isinstance(x, SomeEnum) for x in SomeEnum)). As a consequence, the Enum metaclass prevents subclassing of Enums with defined members. This is a reasonable design choice, but one that limits the applicability of the standard library enum solution for use cases that currently rely on this feature of a custom enum implementation (including flufl.enum, the original inspiration for this feature). An alternative reasonable design choice is to allow extension of enumerations (similar to flufl.enum) and relax the invariant to Enum members are an instance of that Enum or an Enum-derived parent class of that Enum (i.e. assert (all(issubclass(type(x), Enum) and type(x) in SomeEnum.mro() for x in SomeEnum)) There is no need to support this directly in the standard library, but it would be valuable to make it straightforward to support in an Enum variant by subclassing the standard metaclass (similar to the customisation mechanisms provided to support things like autonumbered enums through a derived metaclass). Currently, implementing this behaviour involves overriding a private method of the metaclass (EnumMetaclass._get_mixins) -- messages: 188920 nosy: ncoghlan priority: low severity: normal stage: needs patch status: open title: Support creation of extensible enums through metaclass subclassing type: enhancement versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17954] Support creation of extensible enums through metaclass subclassing
Changes by Nick Coghlan ncogh...@gmail.com: -- dependencies: +Code, test, and doc review for PEP-0435 Enum ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17954] Support creation of extensible enums through metaclass subclassing
Ethan Furman added the comment: I'm sure this is a dumb question, but I have lots of them so thought I'd share. Can this issue be resolved simply by making the `_get_mixins` method `get_mixins`? -- nosy: +ethan.furman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
