[issue17959] Alternate approach to aliasing for PEP 435
Changes by Barry A. Warsaw ba...@python.org: -- nosy: +barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17959] Alternate approach to aliasing for PEP 435
Barry A. Warsaw added the comment: On May 12, 2013, at 06:51 AM, Nick Coghlan wrote: class Shape(Enum): ... square = 2 ... diamond = 1 ... circle = 3 ... alias_for_square = square I see Guido pronounced against it, but I'm just registering that I kind of like this. You could probably have guess that since flufl.enum doesn't allow aliases at all mostly because of the potential for accidental duplicate values, which this would avoid. Hmm. LP: #1179529 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17959] Alternate approach to aliasing for PEP 435
Nick Coghlan added the comment: I just wanted to note that there's a trivial way to prevent accidental aliases inline or in your test suite if you don't intend them: class MyEnum(Enum): assert len(MyEnum) == len(MyEnum.__members__) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17959] Alternate approach to aliasing for PEP 435
New submission from Nick Coghlan: Creating this as a separate issue so as not to delay incorporation of the accepted PEP. One legitimate criticism of the accepted PEP 435 is that the combination of requiring explicit assignment of values *and* allowing aliasing by default is that aliases may be created inadvertently. I believe we can actually do better than the initial implementation by making the following work: class Shape(Enum): ... square = 2 ... diamond = 1 ... circle = 3 ... alias_for_square = square ... Shape.square Shape.square: 2 Shape.alias_for_square Shape.square: 2 Shape(2) Shape.square: 2 While *disallowing* the following: class Shape(Enum): ... square = 2 ... diamond = 1 ... circle = 3 ... alias_for_square = 2 ... How, do you ask? By wrapping non-descriptors on assignment in a placeholder type, and keeping track of which values we have already seen. If a new attribute is mapped to a placeholder, then that's fine, we accept it as an explicit declaration of an alias. However, if it's mapped directly to a repeat value, then that would be disallowed (as it was in earlier versions of the PEP). -- messages: 188981 nosy: ncoghlan priority: normal severity: normal stage: needs patch status: open title: Alternate approach to aliasing for PEP 435 type: enhancement versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17959] Alternate approach to aliasing for PEP 435
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/issue17959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17959] Alternate approach to aliasing for PEP 435
Alex Gaynor added the comment: This would preclude code like: class Shape(Enum): rectangle = shape = 2 which seems (to me) to be the most reasonable way to express aliasing. -- nosy: +alex ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17959] Alternate approach to aliasing for PEP 435
Nick Coghlan added the comment: That's a terrible way to express aliasing, because it's really unclear that rectangle is the canonical name. By contrast: class Shape(Enum): rectangle = 2 oblong = rectangle leaves no doubt as to which is canonical and which is the alias. You never need to go beyond two assignments, as you can still use multiple target assignment for the aliases. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17959] Alternate approach to aliasing for PEP 435
Changes by Nick Coghlan ncogh...@gmail.com: -- priority: normal - high ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17959] Alternate approach to aliasing for PEP 435
Changes by Eric V. Smith e...@trueblade.com: -- nosy: +eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17959] Alternate approach to aliasing for PEP 435
Ethan Furman added the comment: Another approach to handling this, and other, issues is to allow options to EnumMeta. My original aenum code had the default Enum class as unordered, no duplicates allowed, non-indexable, etc., but then allowed options to be passed in such as DUPLICATES to allow duplicates, ORDERED to add the ge-gt-le-lt methods, INDEXED to add __index__, etc. For the aliasing issue this method is more robust as placeholders are not required, and code like this will work: class Physics(Enum): e = 2.81847 pi = 3.141596 tau = 2 * pi To make that code work with placeholders is possible (I have it in aenum) but a major pain (I was about to remove it before my offer to help with ref435 was accepted). -- nosy: +ethan.furman ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17959] Alternate approach to aliasing for PEP 435
Nick Coghlan added the comment: Hmm, that's an interesting point about allowing operations on the already defined values. You could get around that by requiring that the wrapper be explicit when definined the alias: class Shape(enum.Enum): ... rectangle = 1 ... oblong = enum.alias(rectangle) Or, equivalently: class Shape(enum.Enum): ... rectangle = 1 ... oblong = enum.alias(1) So simple typos would trigger an error by default, and the enum.alias wrapper would tell the namespace (or the metaclass) hey, this should be an alias for another value already defined here. I definitely don't want us to turn the metaclass into a swiss army knife of behavioural options - I'm happy with customisation hooks in the metaclass on that front, as I believe it is an effective way to discourage excessive use of metaclass magic without preventing it when it is necessary. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17959] Alternate approach to aliasing for PEP 435
Changes by Guido van Rossum gu...@python.org: -- nosy: +gvanrossum ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17959] Alternate approach to aliasing for PEP 435
Changes by Stefan Drees ste...@drees.name: -- nosy: +dilettant ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17959] Alternate approach to aliasing for PEP 435
Antoine Pitrou added the comment: That's way too much magic for my taste. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17959] Alternate approach to aliasing for PEP 435
Antoine Pitrou added the comment:
Also, since we currently don't forbid the following:
{'a': 1, 'a': 2}
{'a': 2}
I don't see why enums should be any different. Recommend closing.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17959
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17959] Alternate approach to aliasing for PEP 435
Nick Coghlan added the comment: The difference is the use case: dicts are a general purpose data store, enums are typically for defining mutually exclusive named values, with aliasing as a concession to practical reality. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17959] Alternate approach to aliasing for PEP 435
Guido van Rossum added the comment: I'm with Antoine. Trying to prevent accidental redefinition behavior like Nick proposes feels like un-Pythonic coddling to me, and I expect we'd be closing off some occasionally useful patterns. Please leave well enough alone. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
