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
