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

Steven D'Aprano steve at REMOVE-THIS-cybersource.com.au
Tue Jul 29 19:31:21 EDT 2008


On Tue, 29 Jul 2008 10:42:50 -0700, Carl Banks wrote:

> On Jul 29, 11:12 am, Matthew Fitzgibbons <eles... at nienna.org> wrote:
...
>> 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".

Yet again you ignore the actual functional requirements of the code, and 
made vague claims that if we change the function to another function that 
behaves differently, we can replace our simple code with your more 
complex code, and it (probably) won't break. Even if we could redesign 
the functional requirements of the code, why on earth would we want to?



-- 
Steven



More information about the Python-list mailing list