"0 in [True,False]" returns True

[bonono at gmail.com]

Mike Meyer wrote:
> bonono at gmail.com writes:
> > Steve Holden wrote:
> >> >>It would be somewhat more self-documenting, but why not just use one
> >> >>name to indicate the state and another, only meaningful in certain
> >> >>states, to indicate the callback?
> >> > Why should I do that? Checking the type of a variable is conceptually
> >> > no different form testing set membership. So what I did, was just
> >> > bringing two disjoint sets togther and working with a variable from
> >> > that union. This is all in all a rather simple mathematical idea.
> >> > And I don't see why I should put certain information into a seperate
> >> > variable. It makes as much sense as working with numbers and using
> >> > a seperate variable to store whether a particular number is postive,
> >> > even or has some other characteristic. You don't seperate information
> >> > you can easily acquire from the variable itself. So why should I
> >> > seperate this information that is aquired just as easily?
> >> Well, as you might argue, I'm not tryng to effect a change in your
> >> behaviour, I'm simply trying to point out how it could be made more
> >> rational.
> > What would be the difference in his usage and allowing Null in a RDBMS
> > column ? Or return NaN instead of raising exception for numeric
> > functions ?
>
> Having a value to indicate "no value" is, of course, perfectly
> reasonable. However, you then test *for that value*; you don't test
> the type of the value to see if it's of the right type.
>
> Once you get beyond the variable either having a valid value or not,
> it's really time to consider a different approach. As has been
> indicated, using two variables is ba well-respected method of doing
> this. Another alternative (on the spur of the moment - I have no idea
> how well this will really work) is a value-carrying "invalid value":
>
> # untested code:
> class Invalid:
>     state =  'unknown'
>
> ...
>
>     if self.count is Invalid:
>        if self.count.state == 'unregistered':
>           # Register self.
>        elif self.count.state == 'registered':
>           # Whatever
>     else:
>         # Deal with self.count outstanding requests
>
> Hmm. I'm not sure I like this...
>
He doesn't need to test the type, in this case.

if self.count is False:
elif self.count is True:
else:

The alternative suggested :

if self.state is False:
elif self.state is True:
else: deal with self.count

I don't see much difference. He can also use a better name to represent
True/False.

Registered=True
UnRegistered=False