"0 in [True,False]" returns True

[bonono at gmail.com]

Antoon Pardon wrote:
> Op 2005-12-14, Grant Edwards schreef <grante at visi.com>:
> > On 2005-12-14, Antoon Pardon <apardon at forel.vub.ac.be> wrote:
> >
> >>>>> 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.
> > [...]
> >>>> Or return NaN instead of raising exception for numeric
> >>>> functions ?
> >>>
> >>> Because usually (in my applications anyway) NaN is a perfectly
> >>> valid value and not an "exception" case that needs to be
> >>> handled.
> >>
> >> I don't see the difference. In my application False and True
> >> (or Registered and UnRegistered if you prefer) are perfectly
> >> valid values too.  They are not "exception" cases that need to
> >> be handled.
> >
> > Well, in my case, a given name (or return value) is always
> > bound to a floating point object. I don't test the type of the
> > object and treat it in two different ways depending on what
> > type it is.  It's just a float.
>
> Do you find that difference so important? As far as I understand
> the gtk identifiers are always positive integers. So I could
> have coded as follows:
>
>   UnConnected = (-1, -2)
>   Registered, UnRegistered = UnConnected
>
>   ...
>
>   if self.cb_src in UnConnected:
>
> Now all values are integers and I no longer treat an object different
> depending on type but on value. However conceptually nothing changed.
> My code branches depending on set membership of this attribute.
>
> Could you explain why it should make a (big) difference between
> these two approaches?
That is what I would do in C or similar language where a variable can
only be one type.