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

[Carl Banks]

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