John Hagen added the comment:

@Ethan, I hadn't tried to use the aenum AutoNumberEnum that way, but I agree 
with Barry that I like it.  To me that is the ideal case we should shoot for as 
I think it's the best* long term and deviate only if practical concerns prevent 
it.

So I am +1 for empty member assignment and if that is rejected, +1 for = () 
assignment as at least it is a big step forward.  I feel both solutions already 
have some "magic", so would lean toward the one that leads to the least amount 
of boilerplate.

As for the empty assignment, I have played around with something similar before 
and will throw out one con for it: static analyzers get really confused.  
PyCharm, for example, thinks this is has unresolved references in it:

class Color(AutoNumberEnum):
    red
    green
    blue

But the counter point is that if this is in the stdlib, static analyzer authors 
are much more likely to add a special case for it than if in a "non-official" 
third party package (PyCharm example: 
https://youtrack.jetbrains.com/issue/PY-19150).


Another piece of evidence to support inclusion is that Python already provides 
specialized Enum subclasses (like IntEnum).  I've written a lot of Python code 
that uses Enums and haven't personally needed IntEnum yet, but would have used 
an AutoEnum many, many times.

* I am assuming here that a true "enum" keyword is out of the question at this 
point for Python, which would probably be even better.

----------

_______________________________________
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

Reply via email to