spliting on ":"

[Steve Holden]

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