Carl Banks wrote:
On Jul 28, 8:15 pm, Steven D'Aprano <[EMAIL PROTECTED]
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 <[EMAIL PROTECTED]
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
--
http://mail.python.org/mailman/listinfo/python-list
