[Python-Dev] Re: stdlib Flag Enums and the "no value" member
On 2021-04-29 18:56, Ethan Furman wrote: On 4/29/21 10:52 AM, Antoine Pitrou wrote: > On Thu, 29 Apr 2021 18:37:29 +0100, MRAB wrote: >> On 2021-04-29 18:19, Ethan Furman wrote: >>> An excerpt from bpo-31369: re.RegexFlag and `__all__` >>> >>> GvR: >>> >>>> One thing I discovered when developing this example: there doesn't seem to be a flag to >>>> represent 0 (zero), i.e. "no flags". And foo(0) is a type error (even though it works >>>> fine at runtime). >>> >>> Which raises the question: Do we want to have a standard name for stdlib Flags when no flags are set? >>> >>> What should we call it? >>> >>> - NONE >>> >>> - ZERO >>> >>> - EMPTY >>> >>> - ??? >>> >> Definitely NONE. At some point I might even add it to the regex module! :-) > > Not to confuse with None, which will not be equal to NONE. Hmm... > > Perhaps NONE_SET or ALL_UNSET? > > (also, why the ALL_CAPS?) Since Enum members are constants, ALL_CAPS is recommended for their naming scheme. And the flags of the re module have always been ALL_CAPS. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/DCKIHYXVZIRABF43M3NX75RZAXIQ3AOV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: stdlib Flag Enums and the "no value" member
On Fri, Apr 30, 2021 at 4:28 AM Jonathan Goble wrote: > > On Thu, Apr 29, 2021 at 2:00 PM Ethan Furman wrote: >> >> On 4/29/21 10:35 AM, Jonathan Goble wrote: >> > On Thu, Apr 29, 2021 at 1:20 PM Ethan Furman wrote: >> >> >> >> Which raises the question: Do we want to have a standard name for >> stdlib Flags when no flags are set? >> > >> > If you want a flag to represent no flags set, it takes one line to write >> it yourself, as in this example I copied >> > verbatim from the docs: >> > >> > >>> class Color(Flag): >> > ... BLACK = 0 >> > ... RED = auto() >> > ... BLUE = auto() >> > ... GREEN = auto() >> > ... >> > >>> Color.BLACK >> > >> > >>> bool(Color.BLACK) >> > False >> >> Are you suggesting that the standard name for 0 be 'BLACK'? ;-) > > > Any color you want as long as it's BLACK. ;-) > > But seriously, my point is that it's already trivially possible for enum > authors to give the zero case a name of their own choosing that makes sense > for their use case, so we don't need special automatic names for it. The one > obvious way to do it, and the explicit way to do it, is to define your own > name to be equal to zero. Creating an automatic name for zero now, after the > enum module is well-established, violates the Zen of Python in at least > three, possibly four ways: > > - it's implicit behavior (compared to the explicitness of defining your own > name) > - it violates the "one obvious way to do it" principle (I can conceivably see > arguments developing in the community over whether the automatic name should > be preferred or if one should write an explicit name for zero, as neither is > clearly and obviously better than the other) > - it requires a special case for backward compatibility with the @enum.unique > decorator > - it's arguably ambiguous what object should be returned for foo(0) when an > explicit name is defined (due to the documented behavior that a second name > for the same value is an alias for the first; is the automatic name created > first or last?) > OTOH, zero is already supported. If you create a flag without defining a zero entry, it implicitly gets one with the name None. >>> class Color(Flag): ... RED = auto() ... BLUE = auto() ... GREEN = auto() ... >>> c = Color.GREEN|Color.BLUE >>> c >>> c &= Color.GREEN >>> c >>> c &= Color.BLUE >>> c >>> c.name >>> c.value 0 It makes good sense to have an actual name for it. If the automatic/default name (Color.NONE or whatever name it gets) is considered to be created at the very end of the class definition, this would resolve the ambiguity. And unique() could simply prevent the creation of NONE if there's anything else (eg Color.BLACK) with the value of zero. ChrisA ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/QBWVLDC752PFAADMAM4GYIJGJ7USTRHA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: stdlib Flag Enums and the "no value" member
On Thu, Apr 29, 2021 at 2:00 PM Ethan Furman wrote: > On 4/29/21 10:35 AM, Jonathan Goble wrote: > > On Thu, Apr 29, 2021 at 1:20 PM Ethan Furman wrote: > > > >> Which raises the question: Do we want to have a standard name for > stdlib Flags when no flags are set? > > > > If you want a flag to represent no flags set, it takes one line to > write it yourself, as in this example I copied > > verbatim from the docs: > > > > >>> class Color(Flag): > > ... BLACK = 0 > > ... RED = auto() > > ... BLUE = auto() > > ... GREEN = auto() > > ... > > >>> Color.BLACK > > > > >>> bool(Color.BLACK) > > False > > Are you suggesting that the standard name for 0 be 'BLACK'? ;-) > Any color you want as long as it's BLACK. ;-) But seriously, my point is that it's already trivially possible for enum authors to give the zero case a name of their own choosing that makes sense for their use case, so we don't need special automatic names for it. The one obvious way to do it, and the explicit way to do it, is to define your own name to be equal to zero. Creating an automatic name for zero now, after the enum module is well-established, violates the Zen of Python in at least three, possibly four ways: - it's implicit behavior (compared to the explicitness of defining your own name) - it violates the "one obvious way to do it" principle (I can conceivably see arguments developing in the community over whether the automatic name should be preferred or if one should write an explicit name for zero, as neither is clearly and obviously better than the other) - it requires a special case for backward compatibility with the @enum.unique decorator - it's arguably ambiguous what object should be returned for foo(0) when an explicit name is defined (due to the documented behavior that a second name for the same value is an alias for the first; is the automatic name created first or last?) So I don't see any compelling argument for giving an automatic name for zero. Just define your own name. It takes five seconds and one line, with essentially zero cost to maintainability. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/T3CHW4BTC4K7B5SGZUEFV5JSNCLO3YND/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: stdlib Flag Enums and the "no value" member
On 4/29/21 10:35 AM, Jonathan Goble wrote: > On Thu, Apr 29, 2021 at 1:20 PM Ethan Furman wrote: >> Which raises the question: Do we want to have a standard name for stdlib Flags when no flags are set? > > If you want a flag to represent no flags set, it takes one line to write it yourself, as in this example I copied > verbatim from the docs: > > >>> class Color(Flag): > ... BLACK = 0 > ... RED = auto() > ... BLUE = auto() > ... GREEN = auto() > ... > >>> Color.BLACK > > >>> bool(Color.BLACK) > False Are you suggesting that the standard name for 0 be 'BLACK'? ;-) -- ~Ethan~ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/U365WUWGJBGFVMEXUQUFRPHAONTB7CJP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: stdlib Flag Enums and the "no value" member
On 4/29/21 10:52 AM, Antoine Pitrou wrote: > On Thu, 29 Apr 2021 18:37:29 +0100, MRAB wrote: >> On 2021-04-29 18:19, Ethan Furman wrote: >>> An excerpt from bpo-31369: re.RegexFlag and `__all__` >>> >>> GvR: >>> >>>> One thing I discovered when developing this example: there doesn't seem to be a flag to >>>> represent 0 (zero), i.e. "no flags". And foo(0) is a type error (even though it works >>>> fine at runtime). >>> >>> Which raises the question: Do we want to have a standard name for stdlib Flags when no flags are set? >>> >>> What should we call it? >>> >>> - NONE >>> >>> - ZERO >>> >>> - EMPTY >>> >>> - ??? >>> >> Definitely NONE. At some point I might even add it to the regex module! :-) > > Not to confuse with None, which will not be equal to NONE. Hmm... > > Perhaps NONE_SET or ALL_UNSET? > > (also, why the ALL_CAPS?) Since Enum members are constants, ALL_CAPS is recommended for their naming scheme. -- ~Ethan~ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/WEGL7HPVCLD54QH622WZZLASFIJVE27Y/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: stdlib Flag Enums and the "no value" member
On Thu, 29 Apr 2021 18:37:29 +0100 MRAB wrote: > On 2021-04-29 18:19, Ethan Furman wrote: > > An excerpt from bpo-31369: re.RegexFlag and `__all__` > > > > GvR: > > > > > One thing I discovered when developing this example: there doesn't seem > > to be a flag to > > > represent 0 (zero), i.e. "no flags". And foo(0) is a type error (even > > though it works > > > fine at runtime). > > > > Which raises the question: Do we want to have a standard name for stdlib > > Flags when no flags are set? > > > > What should we call it? > > > > - NONE > > > > - ZERO > > > > - EMPTY > > > > - ??? > > > Definitely NONE. At some point I might even add it to the regex module! :-) Not to confuse with None, which will not be equal to NONE. Hmm... Perhaps NONE_SET or ALL_UNSET? (also, why the ALL_CAPS?) Regards Antoine. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/VWCFG3B4U6IB6TXZO7L2YQSOAVXBJ57N/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: stdlib Flag Enums and the "no value" member
On 2021-04-29 18:19, Ethan Furman wrote: An excerpt from bpo-31369: re.RegexFlag and `__all__` GvR: > One thing I discovered when developing this example: there doesn't seem to be a flag to > represent 0 (zero), i.e. "no flags". And foo(0) is a type error (even though it works > fine at runtime). Which raises the question: Do we want to have a standard name for stdlib Flags when no flags are set? What should we call it? - NONE - ZERO - EMPTY - ??? Definitely NONE. At some point I might even add it to the regex module! :-) ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/RBZ7ILB64FBFEHFQNHKGHJLYNUU3DMET/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: stdlib Flag Enums and the "no value" member
On Thu, Apr 29, 2021 at 1:20 PM Ethan Furman wrote: > An excerpt from bpo-31369: re.RegexFlag and `__all__` > > GvR: > > > One thing I discovered when developing this example: there doesn't seem > to be a flag to > > represent 0 (zero), i.e. "no flags". And foo(0) is a type error (even > though it works > > fine at runtime). > > Which raises the question: Do we want to have a standard name for stdlib > Flags when no flags are set? > > What should we call it? > > - NONE > > - ZERO > > - EMPTY > > - ??? > If you want a flag to represent no flags set, it takes one line to write it yourself, as in this example I copied verbatim from the docs: >>> class Color(Flag): ... BLACK = 0 ... RED = auto() ... BLUE = auto() ... GREEN = auto() ... >>> Color.BLACK >>> bool(Color.BLACK) False ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/UXRKQQWM5HY6ECBBAQ2RUK2TNRJ2AQTT/ Code of Conduct: http://python.org/psf/codeofconduct/
