On Tue, Sep 19, 2017 at 7:21 PM, Antoon Pardon <antoon.par...@vub.be> wrote: > Op 19-09-17 om 09:46 schreef Chris Angelico: >> On Tue, Sep 19, 2017 at 5:22 PM, Antoon Pardon <antoon.par...@vub.be> wrote: >>> But the problem is that the following two pieces of code don't do >>> the same in Python. >>> >>> if x: pass >>> if x is True: pass >>> >> ... >> >> which would be better represented with "if isinstance(x, bool):" >> instead. So "if x is True:" remains odd code, the sort of thing that >> MUST be annotated or I would be raising a red flag. Can you give an >> actual real-world example where this comes up? > > The time I used it was when I had some class that the user had to > somehow activate. An instance could internally be in three states > but the user had only access to two, he had activated it or not. > The internal "active" attribute could be: > > 1) False: The user hasn't activated it. > 2) True: The user has activated it, but there was no active background > machinery yet/anymore. > 3) A handle to the active background machinery. > > Maybe I should have used an internal "state" attribute and an enum > with the values unactivated and activated instead but the use of > False and True in the circumstances above felt rather natural to me.
Fair enough - but that is extremely rare and needs a comment somewhere. But personally, I'd use other singletons rather than False and True. For instance, None to mean "not activated", and have a dedicated object representing the state of "no active background machinery" - an object that has many (or all) of the methods of your machinery object, perhaps. In any case, this is NOT a precedent for normal boolean testing. It's an extreme case where you're doing something abnormal and have abnormal code as a result. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
