"0 in [True,False]" returns True

[Antoon Pardon]

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?

-- 
Antoon Pardon