On Wed, Nov 4, 2020 at 6:11 AM Ethan Furman <et...@stoneleaf.us> wrote:
>
> TL;DR Changes may be coming to Enum str() and repr() -- your (informed)
> opinion requested. :-)
>
> After discussions with Guido I made a (largely done) PR [3] which:
>
> for stdlib global constants (such as RE)
> - repr() -> uses `module.member_name`
> - str() -> uses `member_name`
>
> for stdlib non-global constants, and enums in general
> - repr() -> uses `class.member_name`
> - str() -> uses `member_name`
>
> The questions I would most appreciate an answer to at this point:
>
> - do you think the change has merit?
> - why /shouldn't/ we make the change?
>
Does this affect my own enums too, or just stdlib ones? I'm not
entirely sure on that point.
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.)
I'm fine with the change, but I tend to use the stdlib enums as magic
tokens rather than numbers (I don't care one iota that re.I is 2), so
any clean repr will work just as well for me. +0.9.
ChrisA
_______________________________________________
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/JU5OKUKXCMWR2B7YGB4REAXPVB7QFSHQ/
Code of Conduct: http://python.org/psf/codeofconduct/
