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"<pavlovevide...@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 :)

--
http://mail.python.org/mailman/listinfo/python-list

Reply via email to