"0 in [True,False]" returns True

[Antoon Pardon]

Op 2005-12-14, Mike Meyer schreef <mwm at mired.org>:
> 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.

How do you feel about testing for set membership? I can have a set
with values to be treated differently than values not in the set.
Do you consider that an acceptable approach?

-- 
Antoon Pardon