stdlib Flag Enums and the "no value" member
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 - ??? -- ~Ethan~
On Thu, Apr 29, 2021 at 1:20 PM Ethan Furman <ethan@stoneleaf.us> wrote:
An excerpt from bpo-31369: re.RegexFlag and `__all__`
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
GvR: ---- 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 <Color.BLACK: 0> bool(Color.BLACK) False
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 <Color.BLACK: 0> bool(Color.BLACK) False
Are you suggesting that the standard name for 0 be 'BLACK'? ;-) -- ~Ethan~
On Thu, Apr 29, 2021 at 2:00 PM Ethan Furman <ethan@stoneleaf.us> 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 <Color.BLACK: 0> 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.
On Fri, Apr 30, 2021 at 4:28 AM Jonathan Goble <jcgoble3@gmail.com> wrote:
On Thu, Apr 29, 2021 at 2:00 PM Ethan Furman <ethan@stoneleaf.us> 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 <Color.BLACK: 0> 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 <Color.GREEN|BLUE: 6> c &= Color.GREEN c <Color.GREEN: 4> c &= Color.BLUE c <Color.0: 0> 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
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! :-)
On Thu, 29 Apr 2021 18:37:29 +0100 MRAB <python@mrabarnett.plus.com> 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.
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~
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.
participants (5)
-
Antoine Pitrou -
Chris Angelico -
Ethan Furman -
Jonathan Goble -
MRAB