On 09/08/12 03:27, Bruce Leban wrote:
On Wed, Aug 8, 2012 at 9:59 AM, Oleg Broytmanphd@phdru.name wrote:
On Thu, Aug 09, 2012 at 02:18:53AM +1000, Ben Finney< firstname.lastname@example.org> wrote:
What is a compelling use case for checking precisely for True or False?
To distinguish False and None for a tri-state variable that can have
3 values - "yes", "no" and "unspecified" - True, False and None in Python-speak.
I'd probably write that this way:
if t is None: # not specified elif t: # true else: # false
Which treats None specially, otherwise falls back to the standard Python concept of truth-value or truthiness. Which is just a form of duck-typing.
on the other hand, if I had a variable that could be either a number or True/False, I would probably write:
This sounds like poor design to me, but okay, for the sake of the argument, let's accept that you do.
if t is True: # elif t is False: # else: # use t as a number
just as I would for any other singleton value.
Keeping the duck-typing of truth-values:
if isinstance(t, numbers.Number) and not isinstance(t, bool): ... elif t: # True, or any other true-like value ... else: # False, or any other false-like value pass
There are many subtle variations on this. We surely don't need, or want, to have to cover them in PEP 8.
Why does the PEP say that == True is preferred to is True?
Because there surely are still libraries out there that return 0 and 1 as true/false values. The bool type was introduced in (by memory) Python 2.2 or 2.3, so very old code may fail, or worse, silently do the wrong thing if you use "is True".