On Fri, Apr 30, 2021 at 4:28 AM Jonathan Goble <jcgob...@gmail.com> wrote: > > On Thu, Apr 29, 2021 at 2:00 PM Ethan Furman <et...@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 _______________________________________________ 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/
