Message265237
@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. |
|
Date |
User |
Action |
Args |
2016-05-10 11:17:13 | John Hagen | set | recipients:
+ John Hagen, barry, eli.bendersky, ethan.furman |
2016-05-10 11:17:13 | John Hagen | set | messageid: <1462879033.02.0.191907728888.issue26988@psf.upfronthosting.co.za> |
2016-05-10 11:17:13 | John Hagen | link | issue26988 messages |
2016-05-10 11:17:11 | John Hagen | create | |
|