Checking against NULL will be eliminated?

[Steven Howe]

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

How true that axiom is. Never more so then when faced with a programming 
language fix like PEP 4000. Fortunately for me, I never trusted python's 
complex, or should I say 'overloaded' Boolean usage.

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

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

if truly Boolean and want to 'do' something on False, then I use 'not'.

I really like 'types'. Helps error checking, helps making logic flows 
cleaner and less error prone. And since 'pydev/Eclipse' is so good at 
finding my from/imports and inserting them for me, I use types liberally.

I guess being an old C programmer makes one a bit more cautious; nothing 
worse then compiler errors, accept runtime errors. And over course, I 
still use lots of parentheses to group my logic. Hell, I still do a lot 
of that when using bash.

So PEP 4000, go ahead, break some over indulgent code and coders; I'm 
not bothered.

Steven


On 03/02/2011 07:15 AM, Tom Zych wrote:
> On Wed, 02 Mar 2011 06:37 -0800, "Carl Banks"<pavlovevidence at gmail.com>
> wrote:
>> The larger reason is that boolean evaluation in Python tries to be too
>> many things: for some types is means "not zero", for some types it
>> means "empty", and for some types it means "this is a value of this
>> type as opposed to None".  That causes conflicts when more than one of
>> those tests makes sense for a given type, as it does with Elements.
> You're right.
>
> PEP 4000:
> Proposing a new, backwards-incompatible version of Python in which
> boolean evaluation
> is not so overloaded.
>
> Hmm, no, I don't think that will fly. We're stuck with it :(
>
> Fortunately there are work-arounds for the cases that matter, as we've
> seen.
> Yay Python :)
>