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

[Matthew Fitzgibbons]

Carl Banks wrote:
> 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?
>>> Use case, please.  I'm asking for code, not arguments.  Please give me a
>>> 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
> --
> http://mail.python.org/mailman/listinfo/python-list
> 

My use case involves a DAG of filters that pass data (of a variety of 
types--filters just pass on data types they don't understand) between 
them. I can also drop out of the filter chain at any point, using 
critera determined by the filters. These criteria, you guessed it, are 
bound to __nonzero__ in the filter and I determine whether or not to 
continue through the graph using "if x". You can't code explicit tests 
if you don't know what the tests even are beforehand. Also, I wanted to 
support builtins (ints and lists in particular) because they can be 
meaningful inputs to filters. Finally, as I add more filters and data 
types, I don't want to go back and mess with the code that decides 
whether or not to break out of the graph.

-Matt