"0 in [True,False]" returns True

[Antoon Pardon]

Op 2005-12-13, Steve Holden schreef <steve at holdenweb.com>:
> Antoon Pardon wrote:
>> Op 2005-12-13, Chris Mellon schreef <arkanes at gmail.com>:
> [...]
>>>If you have a consistent API and you're checking for error values from
>>>your GTK functions, then you already have a lot more code than using 2
>>>varaibles will cost you. 10 lines, maybe.
>>>
>>>The fact that you think setting two variables is "too hard" but you're
>>>perfectly happy with checking for boolean types instead just testing
>>>truth values I think is a real problem.
>> 
>> 
>> These aren't just truth values. If I would have to go split in 
>> meaningfull truth values I would need at least three variables.
>> 
>> 
>>>You aren't saving yourself any
>>>performance. You're barely even saving yourself any typing, and you're
>>>making your code (intentionally, it seems) that much more compllicated
>>>and hard to understand.
>> 
>> 
>> There is nothing complicated or hard to understand.
>> 
> Nope, just a messy, hard to maintain misuse of a single variable for 
> multiple purposes.

No that variable has just one purpose, noting the state of the tube.

> Perfectly simple, perfectly easy to understand and 
> rather more bug-prone that a straightforward separation of state and 
> other data.

What you call other date is IMO just state information.

>> I find it odd that each time declaration are mentioned people here
>> react very rejecting and say that one of the features they love
>> about python is the freedom that a name is not limited to a variable
>> of one type, while when someone makes use of that freedom labeling
>> such code as code smell.
>> 
> There's a difference between using a single name to refer to values of 
> polymorphic types (which can therefore all be handled by the same code) 
> and using the same name to reference state information in one case (this 
>   item has no connected callback) and other data (the callback is to 
> such-and-such an object).
>
>> But lets make an effort to make the code more readable. What
>> about the following suggestion. I use a kind of EnumType with
>> two values: NotRegistered and Registerd. And the name of the
>> type is NotConnected. So I can then write
>> 
>>   if type(self.callback) is NotConnected.
>> 
>> Would that be selfdocumenting enough for you?
>> 
> 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?

-- 
Antoon Pardon