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

[Matthew Fitzgibbons]

Carl Banks wrote:
> On Aug 1, 8:49 am, Matthew Fitzgibbons <eles... at nienna.org> wrote:
>> Carl Banks wrote:
>>> On Jul 31, 11:44 pm, Carl Banks <pavlovevide... at gmail.com> wrote:
>>> [snip excellent explanation of why it's hard to for "if x" to be
>>> extensively polymorphic]
>>> By the way, one thing I forgot to mention is Matt Fitzgibbons' filter
>>> example.
>>> As I said, it's hard to write code that works for both numeric and
>>> container types because they share so few methods.  However, sometimes
>>> you don't know ahead of time what methods are used!  When you're doing
>>> functional programming you might pass in a method that calls the
>>> appropriate method, like so:
>>> def apply_if_true(func,x):
>>>     if x:
>>>         func(x)
>> I find myself doing things like this surprisingly often. All you've done
>> is move the decision as to what function is applied to x elsewhere. Like
>> a factory, for example. I could see using something like this where func
>> prepares object x to be inserted into a database, and you want to make
>> sure x is meaningful first.
>>
>> def add_to_db(prep_func, x):
>>      if x:
>>          entry = prep_func(x)
>>          add_to_db(entry)
>>
>> 'if x' strikes me as better for this case because you might want to
>> accept a non-empty list (or some other objects) but reject non-empty
>> lists. 'if x is None' would not work. It still may be susceptible to the
>> empty iterator problem, depending on what prep_func does.
> 
> What if what you consider to be "meaningful" doesn't happen to
> coincide with what Python considers to be "something".  For instance,
> what if being non-negative is what makes an integer meaningful?  You
> can't use "if x" for that.  What if any list, including an empty one,
> is meaningful, but you want to indicate the possibility of an
> unmeaningful value by passing None?  You can't use "if x" for that.
> 
> So, you might address this issue by doing something like this:
> 
> def add_to_db(prep_func, is_meaningful, x):
>      if is_meaningful(x):
>          entry = prep_func(x)
>          add_to_db(entry
> 
> But if you do that, what has the polymorphism of "if x" gained you?
> 
> The thing it gained for you before is not having to pass in a
> condition: whether x was a sequence, number, or whatever, the same
> condition could be used, and thus you avoided considerable
> complexity.  But if you have to perform tests for which the implicit
> boolean doesn't work, that complexity has to be added to the code
> anyway.

Of course. If a chunk of code already does what you want it to, then you 
can use it. Otherwise you have to do something different. I was just 
pointing out that 'if x' often does what I want it to. Sometimes it 
doesn't, so I do something different.

> 
> That matters in the context of this discussion because it limits the
> usefulness of the polymorphism of "if x" for this functional idiom:
> "if x" only helps you if you have no need for tests that it can't
> handle.
> 
> [snip]
> 
> Carl Banks
> --
> http://mail.python.org/mailman/listinfo/python-list
> 

By this argument, all code is limiting. Obviously, no code can do what 
it can't.

We're not getting anywhere; it's past time to kill this one off.

-Matt