To me it seems like a useful shortcut that means:

 >>> x == True and type(x) == bool

But, as you say, it is best to just let the Python interpreter treat it as a boolean (i.e. within an `if`, it is converted automatically)

Now, I am thinking it would actually be *bad* to have the CPython implementation define `inf` singletons -- imagine a 3rd party library (for example, sympy) that defines '==' for new types:

>>> from sympy import oo
>>> oo == inf
>>> oo is inf
Again, it would be useful for a shortcut: `x is inf` is the same as `x == inf and type(x) == float`, but with 3rd party libraries I don't think it's something good to rely on.

On Mon, Sep 14, 2020, 12:05 AM Steven D'Aprano <> wrote:
On Mon, Sep 14, 2020 at 12:16:54PM +1000, Chris Angelico wrote:

> (How often do people even use "x is True"?)

Alas, that is a common idiom. For example:

It's possibly less common than it used to be now that PEP 8 warns
against it:

and so linters flag it. But I've seen it used by beginners and
experienced programmers alike.

There is some justification for it in the case that you want to test
specifically for the True instance, being much shorter than:

    arbitrary_object == 1 and type(arbitrary_object) is bool

but many people have a mental blindspot and write:

    if flag is True:

even when they know full well that flag is guaranteed to be a bool.

I know that sometimes I catch myself doing the same. I recently
rediscovered some old Pascal code I write in the 1990s and sure enough,
I have "if flag == true" in that too.

Of course we all know that it should be written:

    if flag is True is True:

except I never know when to stop:

    if flag is True is True is True is True is True is True is ...


Python-ideas mailing list --
To unsubscribe send an email to
Message archived at
Code of Conduct: