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

[Carl Banks]

On Jul 29, 6:42 pm, Matthew Fitzgibbons <eles... at nienna.org> wrote:
> Carl Banks wrote:
> > 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".  So it doesn't pass my criterion of being not
> > replaceable with simple explicit test.
>
> > Maybe that's not workable for some reason.  Perhaps if you'd post a
> > code example that shows this, rather than just talking about it, you
> > might be more persuasive.
>
> > Carl Banks
> > --
> >http://mail.python.org/mailman/listinfo/python-list
>
> The no-advance filters have to return the object because I don't just
> forget about it; I evaluate whether I pass it to the next filter or drop
> it in a completely different queue for use in the next stage of the
> operation. True means 'I'm ready to move on to the next stage,' False
> means 'Do the filter thing some more.'

I think I see what you're saying, and yeah I guess that could really
take advantage of polymorphism between very different types.

> Furthermore, the argument that I should just change my API to make a
> 'simple test' work is not very convincing.

I wasn't suggesting you change it: I was trying to ascertain whether
it would have suffered much if you had written it with explicit tests
in the first place, or if Python didn't even have magical booleans.

> The natural, obvious way for
> a filter to work is to pass through the data it operates on; why on
> Earth would it return None? I want to DO something with the data. In
> this case, make a decision about where to pass the data next.

If you don't mind me asking: what do you do actually DO with a zero or
empty list?

> In Java,
> to accomplish this I would have to do lots of introspection and value
> checking (adding more any time I came up with a new kind of input), or
> make a new kind of interface that gives me a method so I can do a
> 'simple test' (including wrappers for ints and arrays and anything else
> I decide to pass in down the road). But Python supports duck typing and
> gives me a handy __nonzero__ method; I can rebind __nonzero__ in my
> filters for my own classes, and ints and lists are handled how I want
> them to be by default. So why jump through hoops instead of just using
> 'if x'?

Ah, so it's just happens to work.  Still, just happening to work
works. (shrug)

> I don't have any postable code (it's in a half way state and I haven't
> touched it for a while), but I'll see if I can't find the time to bang
> something up to give you the gist.

I wouldn't bother at this point.  I was looking to see if someone
could come up with something to disprove my belief on the polymorphic
uselessness of "if x" relative to explicit tests, and if (as I
anticipated) they did not, I could claim that "if x" is really just a
glorified keystroke saver.  But I now realize that the failure of this
bunch doesn't prove anything.  I don't think most people even realize
why answering the question I asked would demonstrate the usefulness of
"if x".

Your example isn't exactly the smoking gun I was looking for, but I
guess we'll have to admit that at least one usage will suffer for not
having it.


Carl Banks