Peter Hansen wrote: > The archives could tell you more, but basically on is usually interested > in *identity* with a singleton object (None), not in whether the object > on is examining happens to compare equal. A custom object could be > designed to compare equal to None in certain cases, even though it *is > not* None, leading to the "== None" approach being defective code.
But if a custom class allows instances to compare as equal to None, we might reasonably expect the programmers had a reason. There's not much anyone can do with None besides passing it around and comparing it by value or identity. Insisting on 'is' rather than '==' will break whatever polymorphism such a custom object was trying to achieve. > In the specific code in question, it won't make any differences, but I > pointed it out to help folks who don't know this to start developing the > safer habit, which is always to use "is" and "is not" with None (or, > generally, with other singletons). Hmmm... To make my code safer, I'm thinking I should replace doc strings that say "if bluf is Null" with "if blurf compares equal to Null". -- --Bryan -- http://mail.python.org/mailman/listinfo/python-list
