On 2008-08-01, Carl Banks <[EMAIL PROTECTED]> wrote:
> On Jul 31, 1:27 pm, "Chris Mellon" <[EMAIL PROTECTED]> 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
--
http://mail.python.org/mailman/listinfo/python-list
