Code basics

[D-Man]

Is there a reason Python puts the 'false' result first?
Could the C/C++/Java ternary operator be added to the language?

Gareth McCaughan wrote:
> 
> 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
> --
> http://www.python.org/mailman/listinfo/python-list