On 11/3/20 11:26 AM, Chris Angelico wrote:
On Wed, Nov 4, 2020 at 6:11 AM Ethan Furman wrote:
TL;DR Changes may be coming to Enum str() and repr() -- your (informed)
opinion requested. :-)
Does this affect my own enums too, or just stdlib ones? I'm not
entirely sure on that point.
That is the primary question under discussion. Unless somebody has a compelling reason not to change the stdlib enums,
that is going to happen.
Specifically, will code like this be affected, and if so, what is the
correct way to be compatible with multiple versions?
from enum import IntFlag, auto
class UF(IntFlag):
SALLY = auto()
PHASEPING = auto()
...
for flag in UF:
print("#define %s %d" % (str(flag), int(flag)), file=f)
Currently, str(UF.SALLY) is "UF.SALLY", but this would change. I'm
guessing the recommendation is "don't do that then"? (For instance,
using flag.name to get "SALLY", and type(flag).__name__ to get "UF",
since these flags won't only come from a single class.)
Assuming the change is made for all Enum, `str(UF.SALLY)` would produce `SALLY`. If that is a common pattern for you
then you could make your own base class and inherit from that:
class C_Enum(Enum):
def __str__(self):
return f"{self.__class__.__name__}.{self._name_}"
--
~Ethan~
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/QQ6AC7I5P6RT5NK75QICR2ZJYOGKKF5I/
Code of Conduct: http://python.org/psf/codeofconduct/
