"0 in [True,False]" returns True

[Antoon Pardon]

Op 2005-12-13, Chris Mellon schreef <arkanes at gmail.com>:
>> > However I must say the coupling in that interface has a very definite
>> > code smell. Why not use two variables, a Boolean "registered" and an
>> > integer ID that is meaningless when registered is False?
>>
>> Because the integer ID can be meaningless when registered is True.
>> If I should use two variables, the "registered" variable should
>> be a three value variable. Something like:
>>
>>   0: Not registered by the user
>>   1: Registered by the user but no internal idle callback registerd
>>   2: internal idle callback registerd
>>
>> Only in the last case is the integer ID meaningfull. But IMO I buy
>> nothing buy seperating the information over two variables. Checking
>> whether the "registered" variable is 2 or not, doesn't buy me
>> anything over checking whether the cb_src is of BooleanType or
>> not.
>>
>> And having the information in one variable means I have to worry
>> less about synchronisation. If I register the internal idle
>> handler I just store its ID in cb_src, without having to worry
>> about another variable that has to be set right.
>>
>
> This is the sort of horrible smelly wretchedness that makes me gag in
> C. Bearing in mind that you of course are free to write your code in
> whatever way you want, and I'm not your boss, this is horrible and
> shouldn't be considered something to be catered for.
>
> First and most importantly, you're replacing a literate,
> self-documenting mechanism with an obtuse one.
>
> if self.userRegisteredCallback:
>
> is much, much better than
>
> if type(self.callback) is bool:

Well either your self-documenting code is not that obvious or
your code doesn't make the same disctinction than the one
you want to replace it with.

And if you want self documenting code then I guess I could rewrite
it as follows

if type(self.callback) is not GtkID:

> 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.

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.

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?

-- 
Antoon Pardon