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.ew...@canterbury.ac.nz> wrote: > 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/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
