On Jul 29, 6:42 pm, Matthew Fitzgibbons <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
