Boolean tests [was Re: Attack a sacred Python Cow]
steven at REMOVE.THIS.cybersource.com.au
Tue Jul 29 11:27:41 CEST 2008
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".
More information about the Python-list