Checking against NULL will be eliminated?

[Steven D'Aprano]

On Wed, 02 Mar 2011 08:20:56 -0800, Steven Howe wrote:

> Back at NCR, they stressed the axiom '90% of the time is spent fixing
> 10% of the code'.

It's not an axiom, it's a platitude. Nor is it based on any objective 
evidence I've ever seen.


> How true that axiom is. Never more so then when faced with a programming
> language fix like PEP 4000. 

Do you realise that "PEP 4000" was Tom Zych being sarcastic? There is no 
PEP 4000:

http://www.python.org/dev/peps/


> Fortunately for me, I never trusted python's
> complex, or should I say 'overloaded' Boolean usage.

That's your loss. Just because you choose to not trust something which 
works deterministically and reliably, doesn't mean the rest of us 
shouldn't.


> If I want to know if a string or list dictionary is empty: if ( len(x)
> == 0 ).

Apart from the unnecessary length and the pointless reliance on an 
implementation detail, can you please explain how the above differs from 
`if not x:`? 

For starters, how about giving an example of a built-in string, list or 
dictionary where `if len(x) == 0` and `if x` give different results?



> If an item is None: if ( type(x) == types.NoneType ):

Good grief, now that truly is astoundingly unpythonic code!

`if x is None` is the right way to do it. It is also *guaranteed* to be 
correct, rather than being subject to failure-modes like this:

>>> import types
>>> types.NoneType = int  # monkey-patch the module
>>> x = 42
>>> if type(x) == types.NoneType:
...     print "And now your world comes crashing down in flames!"
...
And now your world comes crashing down in flames!


No rogue libraries or functions can override the `is` operator or the 
None singleton. I think it is sad that you've been writing code which is 
*less* safe, in the mistaken belief that it was more safe. Perhaps you 
should stop writing C in Python, and learn to write Python.


> nothing
> worse then compiler errors, accept runtime errors.

"I find it amusing when novice programmers believe their main job is 
preventing programs from crashing. ... More experienced programmers 
realize that correct code is great, code that crashes could use 
improvement, but incorrect code that doesn’t crash is a horrible 
nightmare."
-- Chris Smith 
http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/




-- 
Steven