On 9/18/20 3:12 PM, Guido van Rossum wrote:

On 9/18/20 2:44 PM, Ethan Furman wrote:

...

I'm looking for arguments relating to:

- should _convert_ make the default __repr__ be module_name.member_name?

I actually like the status quo for regular enums, when repr() shows the type, name and value, and str() shows "classname.flagname", so I'd stick to that for converted flags. Even though this violates the rule of thumb that repr() should look like a valid expression -- perhaps a stronger rule of thumb is that repr() should show more than str().

Well, if the repr is re.IGNORECASE and the str is 2, then we've met that bar. ;-)

...

- should _convert_ make the default __str__ be the same, or be the numeric value?

Showing just (the str of) the value seems unkind, since e.g. showing '4'makes me think it's just an int. (Then again I can see that for *converted* flags that's not unreasonable.)

But yeah, backwards compatibility. However, I don't think we got any complaints about the `re` flags, did we?

The only complaints I'm aware of were before the re constants became an Enum, but my social media activity consists almost entirely of Stackoverflow. So at this point, I think the choices are: Standard Enum __repr__ __str__ RegexFlag.IGNORECASE and Modified Converted Constant __repr__ __str__ re.IGNORECASE 2 I will admit I fancy the MCC variant more, but we should make a choice and then be consistent. -- ~Ethan~

On 9/18/20 6:41 PM, Guido van Rossum wrote:

On Fri, Sep 18, 2020 at 6:19 PM Ethan Furman wrote:

...

So at this point, I think the choices are:

Standard Enum __repr__ __str__ RegexFlag.IGNORECASE

and

Modified Converted Constant __repr__ __str__ re.IGNORECASE 2

I will admit I fancy the MCC variant more, but we should make a choice and then be consistent.

Hm, there's also what re actually does (tried in 3.8, 3.9 and 3.10): ```

...

...

...

import re print(str(re.I)) RegexFlag.IGNORECASE print(repr(re.I)) re.IGNORECASE

Well, the `str(re.I) == "RegexFlag.IGNORECASE"` is due to a bug I just fixed a couple days ago. The intent, according to a comment in the issue, was that str() and repr() would return the same thing, "re.IGNORECASE".

I honestly think we've already lost consistency.

I counted roughly 25 Enums in the stdlib at this point, and only two of them have modified reprs or strs; and one of those is an internal class. It's worth noting that two others are buggy -- one is being fancy with values and didn't get the custom __new__ correct, they other left in some commas when converting from it's original data type. Most of those 25 were created via [Enum|IntEnum]._convert_ .

Possibly regular enums (Enum, IntEnum, IntFlag) should just all return "class.name" , e.g. 'Color.RED', for both str() and repr(), and "converted" enums should return "module.name ", e.g. 're.IGNORE' for both? It restores the rule of thumb, and it's not unusual. Maybe it's a new trend -- PEP 585's list[int] returns "list[int]" for both str() and repr(). :-)

We could certainly go that route. The value is readily available, even if not printed by default.

At the same time it's as old as Python -- for most builtins other than strings, repr() and str() are the same, and modeled after repr(). Historically, I only introduced the difference between str() and repr() because of strings -- I wanted the REPL to clearly show the difference between the number 42 and the string '42', but at the same time I wanted both to print as just '42'.

Thank you for that -- it's an invaluable debugging tool which I have been grateful for many times.

Another brainstorm (or brainfart): maybe repr() should show the module/class and the name, and str() should only show the name. We'd then get ```

...

...

...

# Mock-up! print(str(re.i)) IGNORE print(repr(re.i)) re.IGNORE

and similar for Color.RED:

...

...

...

# Another mock-up! print(str(Color.RED)) RED print(repr(Color.RED)) Color.RED

I think that's too terse -- the first bit, whether class or module, repr or str, is very important -- especially if you have several enums using some of the same names for their members. -- ~Ethan~

On Sat, Sep 19, 2020 at 1:29 AM Ethan Furman wrote:

On 9/18/20 6:41 PM, Guido van Rossum wrote: [...]

...

Another brainstorm (or brainfart): maybe repr() should show the module/class and the name, and str() should only show the name. We'd then get ```

...

...

...

# Mock-up! print(str(re.i)) IGNORE print(repr(re.i)) re.IGNORE

and similar for Color.RED:

...

...

...

# Another mock-up! print(str(Color.RED)) RED print(repr(Color.RED)) Color.RED

I think that's too terse -- the first bit, whether class or module, repr or str, is very important -- especially if you have several enums using some of the same names for their members.

Hm, the more I think about it the more I like this proposal. :-) When exploring in the REPL, my proposal *would* show the class name (but not the module name -- one can cause obfuscation that way too, but it would become unwieldy, and the custom seems to be top stop short of that). But when printing casually, wouldn't it be nice if we could cause end-user-friendly output to be produced by default? End users probably don't care about the class name, but they would care about the color name. E.g. class Color(Enum): red = 0 green = 1 blue = 2 class Flowers(Enum): roses = 0 violets = 1 def send_bouquet(flowers, color): print("I'm sending you a bouquet of", color, flowers) Looking over the stdlib enums, these usually already have their "kind" encoded in the name, e.g. AF_INET, SOCK_STREAM, SIGINT. And the re flags are pretty unique as well (IGNORE, MULTILINE, DOTALL). -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...

That would be more palatable if it wasn't so common to use manually assigned numerical values (as most of the examples in the enum module docs do) or the default auto(). I'm just trying to present an argument that if the str() of an enum was its name and the repr() was its "full name" (at least including the class) that would be pretty sweet. On Sat, Sep 19, 2020 at 1:02 PM Ethan Furman wrote:

On 9/19/20 11:32 AM, Guido van Rossum wrote:

...

On Sat, Sep 19, 2020 at 1:29 AM Ethan Furman wrote:

...

On 9/18/20 6:41 PM, Guido van Rossum wrote:

...

...

...

Another brainstorm (or brainfart): maybe repr() should show the module/class and the name, and str() should only show the name. We'd then get ```

...

...

> # Mock-up! > print(str(re.i)) IGNORE > print(repr(re.i)) re.IGNORE >

and similar for Color.RED:

...

...

> # Another mock-up! > print(str(Color.RED)) RED > print(repr(Color.RED)) Color.RED >

I think that's too terse -- the first bit, whether class or module, repr or str, is very important -- especially if you have several enums using some of the same names for their members.

Hm, the more I think about it the more I like this proposal. :-)

When exploring in the REPL, my proposal *would* show the class name (but not the module name -- one can cause obfuscation that way too, but it would become unwieldy, and the custom seems to be to stop short of that).

But when printing casually, wouldn't it be nice if we could cause end-user-friendly output to be produced by default? End users probably don't care about the class name, but they would care about the color name. E.g.

class Color(Enum): red = 0 green = 1 blue = 2

class Flowers(Enum): roses = 0 violets = 1

def send_bouquet(flowers, color): print("I'm sending you a bouquet of", color, flowers)

That's a fun example -- but member names are supposed to be UPPER_CASE, so your string would be, for example:

I'm sending you a bouquet of RED VIOLETS

Of course, if we went with the idea of __str__ just returning the value, then:

class Color(Enum): RED = 'red' GREEN = 'green' BLUE = 'blue'

class Flowers(Enum): ROSES = 'roses' VIOLETS = violets'

which would indeed give us:

I'm sending you a bouquet of red violets

and the above enums could be even simpler if using enum.auto() and a custom NamedEnum:

class NamedEnum(Enum): """ member values are the lower-cased member names """ def _generate_next_value_(name, start, count, last_values): return name.lower()

class Flowers(NamedEnum): ROSES = auto() VIOLETS = auto()

-- ~Ethan~ _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/QJX2D56F... Code of Conduct: http://python.org/psf/codeofconduct/

-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-c...

On Sat, Sep 19, 2020 at 11:44 AM Guido van Rossum wrote:

Another brainstorm (or brainfart): maybe repr() should show the module/class and the name, and str() should only show the name. We'd then get ```

...

...

...

# Mock-up! print(str(re.i)) IGNORE print(repr(re.i)) re.IGNORE

and similar for Color.RED:

...

...

...

# Another mock-up! print(str(Color.RED)) RED print(repr(Color.RED)) Color.RED

+1. There's actually a bit of a weird edge case with IntFlag at the moment, and this would bypass that, at least for the str().

...

...

from enum import IntFlag, auto class UF(IntFlag): ... CT_LOW_GRAVITY = auto() ... FLYING = auto() ... UF.CT_LOW_GRAVITY | UF.FLYING str(UF.CT_LOW_GRAVITY | UF.FLYING) 'UF.FLYING|CT_LOW_GRAVITY'

The "UF." prefix is put on the start of the combined group, which means it's not actually evallable (for what it's worth), and it's that bit inconsistent. I'm absolutely fine with removing the classname altogether, so this would show as "FLYING|CT_LOW_GRAVITY". ChrisA

On Fri, 18 Sep 2020 18:14:35 -0700 Ethan Furman wrote:

So at this point, I think the choices are:

Standard Enum __repr__ __str__ RegexFlag.IGNORECASE

and

Modified Converted Constant __repr__ __str__ re.IGNORECASE 2

My vote goes towards the "Standard Enum" choice. "2" in particular is entirely uninformative in this case, since all the code I've ever seen and written uses the symbolic constant, not the numeric value (which as far as I'm concerned is an implementation detail). Regards Antoine.

On 9/22/20 12:11 AM, Serhiy Storchaka wrote:

The only exception is StrEnum -- overriding __str__ of str subclass may be not safe. Some code will call str() implicitly, other will read the string content of the object directly, and they will be different.

Following up on that: >>> import enum >>> >>> class TestStr(enum.StrEnum): ... One = '1' ... Two = '2' ... Three = '3' ... >>> isinstance(TestStr.One, str) True >>> str(TestStr.One) 'TestStr.One' >>> TestStr.One == '1' True I agree, str.__str__ needs to be used in this case. Thanks, Serhiy! -- ~Ethan~