On 2006-10-08, Aahz <[EMAIL PROTECTED]> wrote: > In article <[EMAIL PROTECTED]>, John J. Lee <[EMAIL PROTECTED]> wrote: >>[EMAIL PROTECTED] (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. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
