[Python-Dev] Re: Enum and the Standard Library
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~ ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/TPXCRJAK4S75DO2SYXSGXAB3VAJJZAXU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Enum and the Standard Library
Ethan Furman writes: > 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. +1 for consistency and documentation of guidelines. I have no opinion on what, if anything, to change to get consistency in the stdlib implementations. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/OKL77FRNNDS4NBMEGNZJHD5GBGGA5RIM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] The Python documentation is now compatible with Sphinx 3.2 and newer
Victor Stinner writes: > I discussed with the Sphinx maintainers. They accepted to add two new > options to Sphinx 3.2 to add an opt-in Sphinx 2 compatibility mode: Wow, this is really going the extra mile! Great work, Victor! ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/K4PAHDF3UKDJ6SATR2UI54XTPE4TAORS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Hygenic macros PEP.
On Tue, Sep 15, 2020, at 15:22, Mark Shannon wrote: > > Hi all, > > I'd like to propose a new PEP for hygienic macros. To be clear, "hygienic macros" doesn't *just* mean AST-rewriting macros, it also means being able to define variables within the macro expansion that can't possibly collide with any names in the user code or in any other macros. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/LHNATFDIXG5ZCWM7A2LEMDL6OQBG6WFA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Enum and the Standard Library
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. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/QLPJBFZUPTOOCOJBZ3SLMUCXFKEDCRJB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Enum and the Standard Library
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?)*
[Python-Dev] Re: Enum and the Standard Library
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 -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/QJX2D56FEEMQ5OFJPB5ASXAUM3GUWRPG/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Enum and the Standard Library
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 ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/BEAZU4H3OS3PS45ZRZIVTPDGD7JSPGW7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Enum and the Standard Library
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 -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/QJX2D56FEEMQ5OFJPB5ASXAUM3GUWRPG/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
