In article <[EMAIL PROTECTED]>, Antoon Pardon <[EMAIL PROTECTED]> wrote: >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.
Anyone designing an app like that in Python deserves to lose. It's just another way of shooting yourself in the foot. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "If you don't know what your program is supposed to do, you'd better not start writing it." --Dijkstra -- http://mail.python.org/mailman/listinfo/python-list
