Ethan Furman added the comment: Just so we're clear: I'm going to go with "auto()" and (mostly) use Python's standard routines (with only a little bit of metaclass magic).
Vedran opined: > Since you like examples, what do you say about I love examples! Examples are like pictures, which are worth a thousand words. ;) > class MyEnum(Enum): > red = some_function() > blue = red > > Now, is MyEnum.blue the same as MyEnum.red (watch: not "equal", but > "same")? Yes. > Well, it depends on what some_function returns, right? Nope. > If it returns _auto_, they are not the same, but in all the other > cases, blue is just an alias for red. So object identity depends on > some value that could be external to the class. To me that's > obviously unacceptable. That would be unacceptable. However, it would also be impossible*, because "_auto_" would be injected into the class namespace during "__prepare__()" and be unavailable for an external function to return. * as impossible as anything is in Python -- so really, really difficult > But even "the namespace class body is executed in" _should_ be a Python > namespace, with all its rules. One of those rules is: the namespace is dict-like. Which means it has methods such as __getitem__, __setitem__, etc., which means those methods can implement whatever is needed to give the namespace the desired semantics (within Python syntax). Which, to some extent, is what will be used to transform an instance of "auto" into an appropriate integer. In other words: >>> class Color(Enum): ... red = auto() ... print(red) ... 1 >>> Color.red <Color.red: 1> ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23591> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
