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

[Matthew Fitzgibbons]

Carl Banks wrote:
> On Jul 29, 11:12 am, Matthew Fitzgibbons <eles... at nienna.org> wrote:
>> 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.
> 
> Much like in Steven D'Aprano's example, still the only actual code
> snippet I've seen, it seems that this can easily be done with a simple
> explicit test by having all no-advance filters return None and testing
> with "if x is not None".  So it doesn't pass my criterion of being not
> replaceable with simple explicit test.
> 
> Maybe that's not workable for some reason.  Perhaps if you'd post a
> code example that shows this, rather than just talking about it, you
> might be more persuasive.
> 
> 
> Carl Banks
> --
> http://mail.python.org/mailman/listinfo/python-list
> 

The no-advance filters have to return the object because I don't just 
forget about it; I evaluate whether I pass it to the next filter or drop 
it in a completely different queue for use in the next stage of the 
operation. True means 'I'm ready to move on to the next stage,' False 
means 'Do the filter thing some more.'

Furthermore, the argument that I should just change my API to make a 
'simple test' work is not very convincing. The natural, obvious way for 
a filter to work is to pass through the data it operates on; why on 
Earth would it return None? I want to DO something with the data. In 
this case, make a decision about where to pass the data next. In Java, 
to accomplish this I would have to do lots of introspection and value 
checking (adding more any time I came up with a new kind of input), or 
make a new kind of interface that gives me a method so I can do a 
'simple test' (including wrappers for ints and arrays and anything else 
I decide to pass in down the road). But Python supports duck typing and 
gives me a handy __nonzero__ method; I can rebind __nonzero__ in my 
filters for my own classes, and ints and lists are handled how I want 
them to be by default. So why jump through hoops instead of just using 
'if x'?

I don't have any postable code (it's in a half way state and I haven't 
touched it for a while), but I'll see if I can't find the time to bang 
something up to give you the gist.

-Matt