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
Richard Damon wrote:
On 3/18/19 7:27 AM, Greg Ewing wrote:
if settings[MY_KEY]: ...
That means something VERY different.
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 _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/