question of style

[Paul Rubin]

Steven D'Aprano <steve at REMOVE-THIS-cybersource.com.au> writes:
> > but I don't accept that "somethingness"
> > vs. "nothingness" is the same distinction as truth vs falsehood.
> 
> It's the distinction used by Python since the dawn of time. Python only 
> grew a bool type a few versions back.

That's true, part of the situation we have now is an artifact of that
history.

> I'm not talking about the constants True and False (nouns), but about 
> true and false values (adjectives).

But, it seems to me, the constants True and False are the only values
to which the adjectives "true" and "false" should be applicable to.

> 
> > The idea that the "if"
> > statement selects between "somethingness" and "nothingness" rather than
> > between True and False is a bogus re-imagining of the traditional
> > function of an "if" statement 
> 
> There's nothing bogus about it.
> 
> > and has been an endless source of bugs in Python code.
> I wonder why these "endless" bugs weren't important enough to be 
> mentioned in the rationale to PEP 285:

Because adding the bool type doesn't really fix those bugs.

> describing `if x` as the "correct form" and calling scrapping such a
> feature as "crippling the language".

Certainly, changing "if" would have broken an immense amount of code
and been a completely unworkable approach.  We are using a fairly 
mature language by now; it has a culture and history that carries
certain baggage, as one should expect.

> > Look how much confusion it causes here in the newsgroup all the time.
> The only confusion is that you're causing me. Would you care to link to 
> some?

This current discussion (about bools) came from such confusion just a
few posts up in this very thread:

    From: upwestdon <upwestdon at gmail.com>
    Date: Fri, 3 Jul 2009 23:03:39 -0700 (PDT)
    How about just:

    if not (self.higher and self.lower):
        return self.higher or self.lower

That test was designed to treat None as a boolean False, without
noticing that numeric 0 is also treated as False and could make the
test do the wrong thing.  This is an extremely common type of error.

> > could see some value to having a generic "is_empty" predicate
> We have that already. It's spelled __bool__ or __nonzero__

That's fine, but under the "explicit is better than implicit"
principle, it's preferable to call that predicate explicitly: 
"if bool(x): ..." rather than "if x:".  Also, after many years of
fixing bugs caused by the mushing together of None and False, it seems
to me that we'd have been better off if bool(None) raised an exception
rather than returning false.  None is supposed to denote a nonexistent
value, not a false or empty value.  The only valid way to check
whether something is None should have been "if x is None".  However,
it is of course way too late to do this differently.

> Iterators are a special case, because in general they can't tell if 
> they're exhausted until they try to yield a value.

Right, it would be nice if they supported a lookahead slot, though
that would complicate a lot of __iter__ methods.  There's been various
kludgy attempts to wrap them in ways that support this, though.