[Tutor] beginning to code

[Chris Angelico]

On Tue, Sep 19, 2017 at 7:21 PM, Antoon Pardon <antoon.pardon at 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.pardon at 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