spliting on ":"
steve at holdenweb.com
Mon Mar 6 22:02:20 CET 2006
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".
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
More information about the Python-list