Bryan Olson wrote: > 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. > That's all very well, but completely hypothetical. What's the use case for this theoretical object? Why should anything that isn't None compare equal with it?
None is explicitly defined as a type with a single instance, so comparing equal to None without *being* None seems like a *very* bad idea. > > >>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". > > Humour? regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd www.holdenweb.com Love me, love my blog holdenweb.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
