On 18Mar2019 08:10, Eric Fahlgren <[email protected]> wrote:
On Mon, Mar 18, 2019 at 7:04 AM Rhodri James <[email protected]> wrote:
On 18/03/2019 12:19, Richard Damon wrote:
> On 3/18/19 7:27 AM, Greg Ewing wrote:
>> Juancarlo Añez wrote:
>>
>>> if settings[MY_KEY] is True:
>>> ...
>>
>> If I saw code like this, it would take a really good argument to
>> convince me that it shouldn't be just
>>
>> if settings[MY_KEY]:
>> ...
>>
> That means something VERY different. The first asks if the item is
> specifically the True value, while the second just asks if the value is
> Truthy, it wold be satisfied also for values like 1.
Yes. And the latter is what people almost always mean.
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'".
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 <[email protected]>
_______________________________________________
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
