Code basics

Gareth McCaughan Gareth.McCaughan at pobox.com
Fri Mar 17 19:33:06 EST 2000


Jeff Pinyan wrote:

> Why should the return value of a logic test be "obscure" knowledge?  Why
> "hide" something so basic?

It's generally best to think of true/false values as being
in a type of their own, regardless of how they're actually
implemented in whatever language you're using. It just so
happens that in many languages (examples: C, Perl, Python)
they're 0 and 1. But there's nothing specially Right about
that representation. In Common Lisp, the "false" value is
also a symbol and the empty list; it's not a number. In
all of {C,Perl,Python}, there are other false values
(null pointers, empty strings, the object called None)
and true values (e.g., other non-zero numbers). In
"BBC BASIC", the canonical true value is -1 rather than 1.
In Scheme and Smalltalk, boolean values don't overlap
with other types. And so on.

So, with all this variety of representation of boolean
values, it's a Bad Idea to get the equivalences "false=0,
true=1" so deeply embedded in your brain that constructions
like

    ("no","yes")[a==b]

seem natural to you. If you continue down that road,
the next step will be writing things like

    (n&15)["0123456789ABCDEF"]

in C, and then you're doomed. You might even win the IOCCC.

On a slightly more serious note: If I ask you to list the
two boolean values, which order comes most naturally to you?
I bet it's "true,false", not "false,true". Likewise for
"yes,no". And I bet you find it natural that in every
programming language that has if/then/else, the "then"
clause comes before the "else" clause. -- Now, look again
at that construction above. The "yes" option comes
after the "no" option. If you make a habit of using
that idiom, then I *bet* you it will trip you up some
day.

I understand (at least, I think I understand) the motives
that lead to using this kind of idiom. Python doesn't
have a proper equivalent of C's a?b:c, or Lisp's (if a b c),
and this is sometimes really annoying: once you've got
used to it, the idea of having an if/then/else *expression*
as well as an if/then/else *statement* seems very natural,
and it's annoying to do without it. I feel this too. But
I don't think the best answer is to write unnatural Python.
Best to choose between writing idiomatic Python, and using
some other language. :-)

-- 
Gareth McCaughan  Gareth.McCaughan at pobox.com
sig under construction



More information about the Python-list mailing list