David Hagen added the comment:
> Secondarily, the doesn't seem to be any use case that can't be readily
> covered by the existing classes.
The use case that doesn't have a clean interface in 3.5 at the moment is the
most common use case of enums: just a collection of named objects of given
type; I don't care about the values because they don't really have values apart
from their object identities.
When writing enums in Rust, Swift, C#, etc., the bare identifier not only saves
typing--it allows the developer to explicitly indicate that the underlying
value has no meaning. (It may be better to use "object()" rather than an
integer on AutoEnum, but that is not very important.)
It was said that Python has this feature already:
> Yes, Python 3.4 too: Animal = Enum('Animal', 'ant bee cat dog')
I will concede that this can do what I want. I hope others will concede that
this is not a clean interface. The class name is duplicated and the members are
regexed out of a space-delimited string. This same argument could be made to
deprecate the unnecessary "class" keyword in favor of the "type" function.
I will also concede that there is some deep magic going on in AutoEnum and that
magic should be avoided when it obscures. I personally think the only people
who will be truly surprised will be those who already know Python at a deep
enough level to know that deep magic must be required here. Everyone else will
see "Enum" and a list of bare identifiers, and correctly conclude that this is
your basic enum from everyone other language.
Perhaps an ideal solution would be an enum keyword:
enum PrimaryColor:
red
blue
green
But that's not happening ever.
The next best solution is the current implementation:
class PrimaryColor(AutoEnum):
red
blue
green
But because of the magic, it only barely beats out what I think is the other
great solution already mentioned here:
class PrimaryColor(AutoEnum):
red = ()
blue = ()
green = ()
These two solutions are isomorphic. Both save the developer from having to
provide a (possibly meaningless) value. Both let docstrings be added. Both
provide the ability to reorganize without renumbering. The last one trades
magic for boilerplate.
I'll keep using them from the aenum package if they don't make it into 3.6, but
I think this is a fundamental enough construct that it belongs in the standard
library. It is hard to convince tool maintainers to fully support these until
they are blessed here.
----------
nosy: +David Hagen
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26988>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
