Names changed to protect the guilty

[Antoon Pardon]

On 2006-10-09, Aahz <aahz at pythoncraft.com> wrote:
> In article <slrneik8ap.55m.apardon at rcpc42.vub.ac.be>,
> Antoon Pardon  <apardon at forel.vub.ac.be> wrote:
>>On 2006-10-08, Aahz <aahz at pythoncraft.com> wrote:
>>> In article <877izb1vwe.fsf at pobox.com>, John J. Lee <jjl at pobox.com> wrote:
>>>>aahz at pythoncraft.com (Aahz) writes:
>>>>>
>>>>> The following line of lightly munged code was found in a publicly
>>>>> available Python library...
>>>>> 
>>>>>     if schema.elements.has_key(key) is False:
>>>>> 
>>>>> Sorry, just had to vent.
>>>>
>>>>I think I was reading the same code recently (epydoc?) and was also
>>>>momentarily horrified ;-) until I realized that it was quite
>>>>deliberately using three-valued logic (True, False, None) for some
>>>>presumably-sensible reason.  Since None is false, they had to use
>>>>"is".  So, given the need for three-valued logic, it's not as silly as
>>>>it looks.
>>>
>>> My take is that even in that case, one should use "is" only with None.
>>> There is too much ground for bugs with True/False, particularly if you
>>> either intend to work across version *or* you might possibly accept a
>>> user's object (because *they* might be working across versions and
>>> therefore returning 1/0 instead of True/False).  I think it's safest to
>>> simply ban this idiom.  No exceptions, never.
>>
>>The problem is there is also ground for bugs if you don't use "blah is
>>True". If some application naturally seems to ask for a variable that
>>can be valued False, True or a positive integer then things like "if
>>var" or "if not var" may very well be a bug too.
>
> Anyone designing an app like that in Python deserves to lose.  It's just
> another way of shooting yourself in the foot.

Why? Just because you don't like it? The last time I mentioned this,
all those who propsed an alternative implemenation came with proposals
that couldn't work, while I never had problems with my code.

-- 
Antoon Pardon