# Boolean tests [was Re: Attack a sacred Python Cow]

Carl Banks pavlovevidence at gmail.com
Tue Jul 29 10:37:45 CEST 2008

```On Jul 28, 8:15 pm, Steven D'Aprano <st... at REMOVE-THIS-
cybersource.com.au> wrote:
> On Mon, 28 Jul 2008 13:22:37 -0700, Carl Banks wrote:
> > On Jul 28, 10:00 am, Steven D'Aprano <st... at REMOVE-THIS-
> > cybersource.com.au> wrote:
> >> Cutting to the crux of the discussion...
>
> >> On Sun, 27 Jul 2008 23:45:26 -0700, Carl Banks wrote:
> >> > I want something where "if x" will do but a simple explicit test
> >> > won't.
>
> >> Explicit tests aren't simple unless you know what type x is. If x could
> >> be of any type, you can't write a simple test. Does x have a length? Is
> >> it a number? Maybe it's a fixed-length circular length, and the length
> >> is non-zero even when it's empty? Who knows? How many cases do you need
> >> to consider?
>
> > piece of code where you can write "if x" that works but a simple
> > explicit test won't.
>
> I gave you a piece of code, actual code from one of my own projects. If
> you wouldn't accept that evidence then, why would you accept it now?

I would accept as "evidence" something that satisfies my criteria,
which your example did not: it could have easily (and more robustly)
been written with a simple explicit test.  I am looking for one that
can't.

You keep bringing up this notion of "more complex with no benefit",
which I'm simply not interested in talking about that at this time,
and I won't respond to any of your points.  I am seeking the answer to
one question: whether "if x" can usefully do something a simple
explicit test can't.  Everyone already knows that "if x" requires
fewer keystrokes and parses to fewer nodes.

Carl Banks

```