It came to my attention that: In the original PEP True and False are said to be singletons https://www.python.org/dev/peps/pep-0285/, but it's not in the Data Model https://docs.python.org/3/reference/datamodel.html This came to my attention by code wanting to own the valid values in a dict's key: if settings[MY_KEY] is True: ... If True and False are singletons in the spec (and not only in the CPython implementation), it should be prominent and well known. Cheers, -- Juancarlo *Añez*
On Tue, Mar 19, 2019 at 12:27:04AM +1300, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Three-way (tri state) checkbox. You have to distinguish False and None if the possible valuse are None, False and True.
-- Greg
Oleg. -- Oleg Broytman https://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
Oleg Broytman wrote:
Three-way (tri state) checkbox. You have to distinguish False and None if the possible valuse are None, False and True.
In that case the conventional way to write it would be if settings[MY_KEY] == True: ... It's not a major issue, but I get nervous when I see code that assumes True and False are unique, because things weren't always that way. -- Greg
On Tue, 19 Mar 2019 at 08:42, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
I would argue the opposite - the use of "is" shows a clear knowledge that True and False are each a singleton and the author explicitly intended to use them that way. Use of == in the same context is more likely to indicate a programmer who is unfamiliar with Python's truth rules. Tim Delaney
Tim Delaney wrote:
I don't think you can infer that. It could equally well be someone who's *not* familiar with Python truth rules and really just meant "if x". Or someone who's unfamiliar with booleans in general and thinks that every "if" statement has to have a comparison in it. -- Greg
On Mon, Mar 18, 2019 at 3:42 PM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Regardless of whether it's idiomatic Python code or not, this pattern ("is True:") can be found all over Python code in the wild. If CPython ever broke this guarantee, quite a few popular libraries on pypi would be broken, including pandas, sqlalchemy, attrs and even Python's own standard library: https://github.com/python/cpython/blob/c183444f7e2640b054956474d71aae6e8d31a...
On Tue, Mar 19, 2019 at 11:32:56AM +1300, Greg Ewing wrote:
This! Writing "if some_bool = true" in static typed languages is pretty common. I used to see it a lot in my Pascal days. In fairness that was because I used to write some of it myself :-( For some reason it rarely seems to happen when the flag being tested is itself a boolean expression: if x > 0: # this if (x > 0) is True: # but never this which gives credence to your idea that people expect that people are (consciously or unconsciously) expecting every if to include a comparison. -- Steven
On Tue, Mar 19, 2019 at 09:58:55AM +1300, Greg Ewing wrote:
For a tri-state setting, I would always check for None (or whatever third state was used) first: setting = settings[MY_KEY] if setting is None: # handle third state elif setting: # handle true state else: # handle false state If for some strange reason I required the flags to be precisely True or False rather than arbitrary truthy values, that's a *four* state flag where the fourth state is an error condition. setting = settings[MY_KEY] if setting is None: # handle third state if not isinstance(setting, bool): raise TypeError("not a bool! (but why do I care???)") if setting: # handle true state else: # handle false state
Do you also guard against True and False not being defined at all? As long as True and False have been builtins, it has been a language guarantee that they will be unique. -- Steven
18.03.19 22:58, Greg Ewing пише:
"x == True" looks more dubious to me than "x is True". The latter can be intentional (see for example the JSON serializer), the former is likely was written by a newbie and contains a bug. For example, 1 and 1.0 will pass this test, but 2 and 1.2 will not. Python 3.8 will emit a syntax warning for "x is 1" but not for "x is True", because the latter is well defined and have valid use cases.
On Mon, Mar 18, 2019 at 7:04 AM Rhodri James <rhodri@kynesim.co.uk> wrote:
No, it depends heavily on the context. In GUI code, Oleg's example (tri-state checkbox) is a pervasive idiom. There's lots of code that says "if x is True" or "if x is False" or "if x is None" and that's a very clear indicator that you are dealing with these "booleans that can also be 'unset'".
On 18Mar2019 08:10, Eric Fahlgren <ericfahlgren@gmail.com> wrote:
Yeah, but on a personal basis I would generally write such an idiom as "if x is None: ... elif x: truthy-action else: falsey-action" i.e. only rely on a singleton for the "not set" sentinel (usually None, occasionally something else). Cheers, Cameron Simpson <cs@cskk.id.au>
Richard Damon wrote:
Yes, but there needs to be justification for why the difference matters and why this particular way is the best way to deal with it. Whenever you write 'x is True' or 'x == True', you are putting a burden on all code that assigns to x to ensure that the value is actually an instance of bool rather than just a truthy or falsy value. That's an unusual requiremebt that can lead to obscure bugs. In the tri-state example, the way I would do it is to guard uses of it with 'if x is not None' and then treat the other values as truthy or falsy. -- Greg
There are few cases where I would approve of 'if x is True'. However, the names used in the example suggest it could be one of those rare cases. Settings of True/False/None (i.e. not set) seem like a reasonable pattern. In fact, in code like that, merely "truthy" values are probably a bug that should not pass silently. Obviously this depends on the surrounding code to decide. On Mon, Mar 18, 2019, 5:44 PM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
On Mon, Mar 18, 2019 at 10:14 PM Juancarlo Añez <apalala@gmail.com> wrote:
"Singleton" technically means that there is only one such object. 'None' is a singleton, by language specification; if type(x) is type(None), you can safely assume that x is None. Booleans are a bit more tricky; there will only ever be those two, but they're two. IMO the PEP is minorly inaccurate to use the word "singleton" there, but it's no big deal. As Remi says, the two built-in ones are the only two instances of that type. ChrisA
On 3/18/19 7:32 AM, Chris Angelico wrote:
Which says that the type of True or False isn't a singleton, but those particular values are. There may be other objects with values that are Truthy or Falsey, but if the value actually IS True or False, the object WILL be those particular objects. As a comparison, if the Tuple (1,2) was described as a Singleton, then any computation that generates that value would all need to return the exact same object, but they don't (the language could make that a true statement). When converting a Truthy or Falsey value to True or False, Python will ALWAYS grab those particular objects, and not create a new object with the same value, so they are Singletons, even if the type itself isn't Yes, in many languages the term Singleton is used for Types and not values, and in part that difference is due to that fact that in Python ALL values are objects, and names are just bound to some object, so the idea of Singleton primitive values actually makes sense. -- Richard Damon
'True' is a keyword. (Which is now immutable in Python 3.X?)
https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarc... https://docs.python.org/3/search.html?q=singleton - "Since None is a singleton, testing for object identity (using == in C) is sufficient. There is no PyNone_Check() function for the same reason." https://docs.python.org/3/c-api/none.html?highlight=singleton - "Using a trailing comma for a singleton tuple: a, or (a,)" (?) https://docs.python.org/3/library/stdtypes.html?highlight=singleton#tuple https://docs.python.org/3/library/stdtypes.html#boolean-values https://docs.python.org/3/library/stdtypes.html#truth-value-testing In Python 2:
On Mon, Mar 18, 2019 at 7:34 AM Chris Angelico <rosuav@gmail.com> wrote:
On Tue, Mar 19, 2019 at 7:53 AM Wes Turner <wes.turner@gmail.com> wrote:
In Python 3, the source code token "True" is a keyword literal that always represents the bool value True.
In Python 2, the source code token "True" is simply a name, and there is a built-in of that name. Before it became a built-in, it was common for scripts to have their own definitions of True and False [1], so to avoid unnecessary breakage, they were made assignable in the normal way. Python 3 simplifies this by making them keywords. But either way, the *values* True and False are special, and are the only two instances of the bool type that will ever exist. ChrisA [1] Note that I learned about this in history class; it was before my time.
On Mon, Mar 18, 2019 at 10:32:38PM +1100, Chris Angelico wrote:
"Singleton" technically means that there is only one such object.
True, but it is common to abuse the term to mean only a fixed, small number of such objects, since "duoton" (for two) and "tripleton" (for three) have never caught on. -- Steven
On Tue, Mar 19, 2019 at 12:27:04AM +1300, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Three-way (tri state) checkbox. You have to distinguish False and None if the possible valuse are None, False and True.
-- Greg
Oleg. -- Oleg Broytman https://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
Oleg Broytman wrote:
Three-way (tri state) checkbox. You have to distinguish False and None if the possible valuse are None, False and True.
In that case the conventional way to write it would be if settings[MY_KEY] == True: ... It's not a major issue, but I get nervous when I see code that assumes True and False are unique, because things weren't always that way. -- Greg
On Tue, 19 Mar 2019 at 08:42, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
I would argue the opposite - the use of "is" shows a clear knowledge that True and False are each a singleton and the author explicitly intended to use them that way. Use of == in the same context is more likely to indicate a programmer who is unfamiliar with Python's truth rules. Tim Delaney
Tim Delaney wrote:
I don't think you can infer that. It could equally well be someone who's *not* familiar with Python truth rules and really just meant "if x". Or someone who's unfamiliar with booleans in general and thinks that every "if" statement has to have a comparison in it. -- Greg
On Mon, Mar 18, 2019 at 3:42 PM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Regardless of whether it's idiomatic Python code or not, this pattern ("is True:") can be found all over Python code in the wild. If CPython ever broke this guarantee, quite a few popular libraries on pypi would be broken, including pandas, sqlalchemy, attrs and even Python's own standard library: https://github.com/python/cpython/blob/c183444f7e2640b054956474d71aae6e8d31a...
On Tue, Mar 19, 2019 at 11:32:56AM +1300, Greg Ewing wrote:
This! Writing "if some_bool = true" in static typed languages is pretty common. I used to see it a lot in my Pascal days. In fairness that was because I used to write some of it myself :-( For some reason it rarely seems to happen when the flag being tested is itself a boolean expression: if x > 0: # this if (x > 0) is True: # but never this which gives credence to your idea that people expect that people are (consciously or unconsciously) expecting every if to include a comparison. -- Steven
On Tue, Mar 19, 2019 at 09:58:55AM +1300, Greg Ewing wrote:
For a tri-state setting, I would always check for None (or whatever third state was used) first: setting = settings[MY_KEY] if setting is None: # handle third state elif setting: # handle true state else: # handle false state If for some strange reason I required the flags to be precisely True or False rather than arbitrary truthy values, that's a *four* state flag where the fourth state is an error condition. setting = settings[MY_KEY] if setting is None: # handle third state if not isinstance(setting, bool): raise TypeError("not a bool! (but why do I care???)") if setting: # handle true state else: # handle false state
Do you also guard against True and False not being defined at all? As long as True and False have been builtins, it has been a language guarantee that they will be unique. -- Steven
18.03.19 22:58, Greg Ewing пише:
"x == True" looks more dubious to me than "x is True". The latter can be intentional (see for example the JSON serializer), the former is likely was written by a newbie and contains a bug. For example, 1 and 1.0 will pass this test, but 2 and 1.2 will not. Python 3.8 will emit a syntax warning for "x is 1" but not for "x is True", because the latter is well defined and have valid use cases.
On Mon, Mar 18, 2019 at 7:04 AM Rhodri James <rhodri@kynesim.co.uk> wrote:
No, it depends heavily on the context. In GUI code, Oleg's example (tri-state checkbox) is a pervasive idiom. There's lots of code that says "if x is True" or "if x is False" or "if x is None" and that's a very clear indicator that you are dealing with these "booleans that can also be 'unset'".
On 18Mar2019 08:10, Eric Fahlgren <ericfahlgren@gmail.com> wrote:
Yeah, but on a personal basis I would generally write such an idiom as "if x is None: ... elif x: truthy-action else: falsey-action" i.e. only rely on a singleton for the "not set" sentinel (usually None, occasionally something else). Cheers, Cameron Simpson <cs@cskk.id.au>
Richard Damon wrote:
Yes, but there needs to be justification for why the difference matters and why this particular way is the best way to deal with it. Whenever you write 'x is True' or 'x == True', you are putting a burden on all code that assigns to x to ensure that the value is actually an instance of bool rather than just a truthy or falsy value. That's an unusual requiremebt that can lead to obscure bugs. In the tri-state example, the way I would do it is to guard uses of it with 'if x is not None' and then treat the other values as truthy or falsy. -- Greg
There are few cases where I would approve of 'if x is True'. However, the names used in the example suggest it could be one of those rare cases. Settings of True/False/None (i.e. not set) seem like a reasonable pattern. In fact, in code like that, merely "truthy" values are probably a bug that should not pass silently. Obviously this depends on the surrounding code to decide. On Mon, Mar 18, 2019, 5:44 PM Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
On Mon, Mar 18, 2019 at 10:14 PM Juancarlo Añez <apalala@gmail.com> wrote:
"Singleton" technically means that there is only one such object. 'None' is a singleton, by language specification; if type(x) is type(None), you can safely assume that x is None. Booleans are a bit more tricky; there will only ever be those two, but they're two. IMO the PEP is minorly inaccurate to use the word "singleton" there, but it's no big deal. As Remi says, the two built-in ones are the only two instances of that type. ChrisA
On 3/18/19 7:32 AM, Chris Angelico wrote:
Which says that the type of True or False isn't a singleton, but those particular values are. There may be other objects with values that are Truthy or Falsey, but if the value actually IS True or False, the object WILL be those particular objects. As a comparison, if the Tuple (1,2) was described as a Singleton, then any computation that generates that value would all need to return the exact same object, but they don't (the language could make that a true statement). When converting a Truthy or Falsey value to True or False, Python will ALWAYS grab those particular objects, and not create a new object with the same value, so they are Singletons, even if the type itself isn't Yes, in many languages the term Singleton is used for Types and not values, and in part that difference is due to that fact that in Python ALL values are objects, and names are just bound to some object, so the idea of Singleton primitive values actually makes sense. -- Richard Damon
'True' is a keyword. (Which is now immutable in Python 3.X?)
https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarc... https://docs.python.org/3/search.html?q=singleton - "Since None is a singleton, testing for object identity (using == in C) is sufficient. There is no PyNone_Check() function for the same reason." https://docs.python.org/3/c-api/none.html?highlight=singleton - "Using a trailing comma for a singleton tuple: a, or (a,)" (?) https://docs.python.org/3/library/stdtypes.html?highlight=singleton#tuple https://docs.python.org/3/library/stdtypes.html#boolean-values https://docs.python.org/3/library/stdtypes.html#truth-value-testing In Python 2:
On Mon, Mar 18, 2019 at 7:34 AM Chris Angelico <rosuav@gmail.com> wrote:
On Tue, Mar 19, 2019 at 7:53 AM Wes Turner <wes.turner@gmail.com> wrote:
In Python 3, the source code token "True" is a keyword literal that always represents the bool value True.
In Python 2, the source code token "True" is simply a name, and there is a built-in of that name. Before it became a built-in, it was common for scripts to have their own definitions of True and False [1], so to avoid unnecessary breakage, they were made assignable in the normal way. Python 3 simplifies this by making them keywords. But either way, the *values* True and False are special, and are the only two instances of the bool type that will ever exist. ChrisA [1] Note that I learned about this in history class; it was before my time.
On Mon, Mar 18, 2019 at 10:32:38PM +1100, Chris Angelico wrote:
"Singleton" technically means that there is only one such object.
True, but it is common to abuse the term to mean only a fixed, small number of such objects, since "duoton" (for two) and "tripleton" (for three) have never caught on. -- Steven
participants (15)
-
Cameron Simpson -
Chris Angelico -
David Mertz -
Eric Fahlgren -
Greg Ewing -
Juancarlo Añez -
Oleg Broytman -
Rhodri James -
Richard Damon -
Rémi Lapeyre -
Serhiy Storchaka -
Stephan Hoyer -
Steven D'Aprano -
Tim Delaney -
Wes Turner