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

[Antoon Pardon]

On 2008-08-01, Carl Banks <pavlovevidence at gmail.com> wrote:
> On Jul 31, 1:27 pm, "Chris Mellon" <arka... at gmail.com> wrote:
>> I'm really not sure where you're going with this or what you're trying
>> to prove. "if x" is a duck-type test for a boolean value. Obviously if
>> you know the type and want a more *specific* test, then you can use an
>> explicit one. Any time you don't know or don't care about a more
>> specific type than "something which probably is boolean true", or any
>> time where you know the boolean semantics of the type and want to drop
>> some typing, you can use "if x". The more specific test is what you'd
>> use if you want more specific results. What's complicated about this
>> idea?
>
> Many people trumpet that "if x" makes your code more polymorphic
> whenever this comes up--in fact you just repeated the claim--without
> ever considering how rarely this more extensive polymorphism comes up
> in practice.   I was calling them out to say "prove to me that it
> actually happens".
>
> I believe it's very rare not to know enough about the expected type
> that explicit tests won't work.  We've uncovered a few examples of it
> in this thread, but IMO we haven't uncovered any sort of broad, wide-
> ranging use cases.

I was reading this thread and was wondering about the following problem.

I have a loop that continuously calculates something. I also have a
producer that may produce extra input that can influence the
calculations. The producer can also indicate the loop should finish.

So the result of produce can be three things:

  1) A not empty sequence; indicating available input.

  2) An empty sequence; indicating no input available now.

  3) None; indicating the end of the calculations.


So the loop essentially looks like this:

while 1:
  extra = produce()
  if extra is None:
    break
  for el in extra:
    adjust_with(el)
  calculate()


I now have the following question for people who argue that "if x"
is more polymorphic. I could subclass list, so that instances
of this new sequence would always behave as true, even if they are
empty.  I could then rewrite my loop as follows:

while 1:
  extra = produce()
  if not extra:
    break
  for el in extra:
    adjust_with(el)
  calculate()

Is this second loop now more polymorphic as the first?

Personnaly I would argue that the first loop with the more specific
test is more polymorphic in this case, as it works with the standard
sequence semantics of python; so the first loop will work with
produce, producing any kind of sequence while the second loop
will only work with produce producing a specific kind of sequence.

-- 
Antoon Pardon