question about True values

[John Coleman]

Donn Cave wrote:
> In article <1161812827.596356.316450 at f16g2000cwb.googlegroups.com>,
>  "John Coleman" <jcoleman at franciscan.edu> wrote:
>
> > Very good point, though one could argue perhaps that when one is
> > comparing an object with a truth value then one is implicitly asking
> > for the truth value of that object
>
> On the contrary -- since there is normally no need to ever
> compare an object with a truth value, then I would interpret
> this usage as an attempt to distinguish True or False from
> other objects in general.  Some kind of placeholders for
> missing values, who knows.  I'm not saying it's a great idea,
> but it could work in recent versions of Python.
>
> > This would make code like 'if s: ' equivalent
> > to 'if s == True:' with a possible gain in readability. But - as you
> > demonstrate the cost of that (minimal) gain in readability would be too
> > high. In any event - I think it is mostly bad style to use a
> > non-boolean variable in 'if s:' - it reminds me too much of obscure C
> > code (though others might disagree).
>
> Others will indeed disagree.  I don't think you'll find
> much support for this position.  But it's not as bad as
> your notion that "if s == True", where s is not a boolean
> object, might represent a gain in readability.  That really
> redefines readability.
>
>    Donn Cave, donn at u.washington.edu

As far as readability goes - most computer languages have a surface
syntax which is (by design) vaguely similiar to the syntax of a natural
language like English. Thus statements roughly correspond to sentences.
For example, you can see a subject-verb-object pattern in "x=3". Given
a genuinely boolean construct like x < 2, "if x < 2:" *sounds* right to
a human reader. Similarly, given a good boolean variable with a
descriptive name like "found", the fragment "if found:" sounds ok. But
- given a non-boolean variable like "product_name" -  writing "if
product_name:" sounds (to my ears) a little jarring - it sounds like a
sentence fragment. It's like saying "If Bob" - If Bob *what*? Goes to
the store? answers the telephone? Finish the damn thought! Now, if you
were to (from some strange reason) use "product_name" as if it were a
truth value then (to my ears) it would both make your intentions more
clear and sound less fragmentary if you could say "if product_name ==
True:". When you use "product_name" as the condition of an if statement
then in that context it is *functioning* as a truth value so (naively)
what could be wrong with comparing it to a truth value? I don't
advocate any change in Python here - just pointing out that the idea of
allowing "if s:" and "if s == True:" to be always equivalent in the
interest of readability isn't *that* strange. It doesn't constitute a
redefinition of readability.

As far as using non-booleans as conditions - I just think that if you
want a certain block of code to be executed only if, for example, a
list is non-empty, why not *say* so? I think "if my_list != []:" just
reads better than "if my_list:". I would think that my preferences
there mesh with "Explicit is better than implicit" but apparently not.

I'm just starting out with Python with most of my programming in recent
years being in various dialects of Visual Basic (which probably
explains a lot). What attracts me to Python so far is the cool slice
operations, the iterators, the libraries and the convience of
programming in a REPL environment. So far, the ability to use "cat" as
a part-time substitute for True just strikes me as a curiousity - but
maybe that will change with time.

-John Coleman