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

[Steven D'Aprano]

On Tue, 29 Jul 2008 01:37:45 -0700, 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.

Only at the cost of completely ignoring the functional requirements and 
changing the API. In other words: you ignore my code, and invent your own 
imaginary code that does something completely different, then say that 
this imaginary code is better.

And I question your assertion that a "simple explicit test" is more 
robust. Where's your evidence for that?



> I am looking for one that can't.

If you are writing code that needs to do the right thing with arbitrary 
types, then your so-called "simple explicit tests" simply can't work. If 
your code isn't expected to deal with arbitrary types, then you've got an 
excellent chance that it will work, because you know what types to expect.

Until somebody passes a type that you didn't expect, and your code fails 
because it makes assumptions about the object.

If you know that you only get lists, then "if len(x)!=0" is a perfectly 
good test (apart from being longer to type, harder to read, and slower to 
execute than "if x"). It will work so long as you only get objects where 
a length of zero is equivalent to being false. That's a good assumption 
to make, but it is an *unnecessary* assumption. Any reasonable object you 
get will know if it is false/nothing or true/something, so why make any 
assumptions? Just ask the object. It knows.


 
> 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.

Of course not.



> I am seeking the answer to one
> question: whether "if x" can usefully do something a simple explicit
> test can't.

"if x" is completely type agnostic. You can pass an object of any type to 
it, and it will work. (Excluding objects with buggy methods, naturally.)

Try doing that with one of your so-called "simple explicit tests".



-- 
Steven