Carl said:
I think I see what you're saying, and yeah I guess that could really
take advantage of polymorphism between very different types.
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.
Yes it would have suffered. I chose the implementation I did because it
made the most sense to me and was the most flexible (a key requirement).
Instead of cobbling together my own way, I used the way that Python gave me.
Python doesn't have magic booleans. They are instead a very well-defined
language mechanism that isn't perfect for every circumstance, but is
pretty good for the most part. I wanted to do meaningful boolean tests
on various objects, so I used the mechanism that my language gave me.
If you don't mind me asking: what do you do actually DO with a zero or
empty list?
Depends on exactly what the next stage is. Typically, zeros and empty
lists are not meaningful for the next stage, so they get dropped then if
they make it through. I don't want to restrict what gets passed through,
though, because I could end up with several meaningful data types,
making a simple test again impossible. So I pass everything through and
let the next stage decide.
Ah, so it's just happens to work. Still, just happening to work
works. (shrug)
Nonono. The point you seem to be missing is that 'if x' is very well
defined. There is nothing magic or arbitrary about what it does. It
works here and elsewhere because Python (a) chooses good default
behavior (its treatment of lists and ints, etc) and (b) gives you a way,
__nonzero__, to change the behavior to suit your needs.
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".
Of course you don't _need_ to have 'if x'; after all, <sarcasm>REAL
programmers code in machine language</sarcasm>. The whole point of a
high-level language is to make life easier. Python is very dynamic and
allows duck typing so that you can use these tools to do clever things
that would otherwise be very difficult. It even gives you a handy
polymorphic mechanism to do boolean tests, which my example illustrates.
You asked for a use case for a polymorphic 'if x' that can't be easily
replaced by a simple test. I gave one. Then you asked for a code sample,
but now have dismissed my sample as not compelling without having seen
it. But here it is anyway (attached). It's pretty rough since I just
threw it together. I'm sure there are mistakes. I also dropped the DAG,
where all the queueing and decision making is handled in the actual
program. The filters and data are arbitrary but should illustrate the
setup. You care about line 66. Again, the same thing could be
accomplished in various ways; but keep in mind that data could be
_anything_, so you can't easily rewrite line 66.
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
So you hypothesized that you can easily rewrite any 'if x' as a simple,
explicit test. I produced an example that shows this cannot be done;
therefore your hypothesis is not correct.
For most cases, you can come up with a simple test, even if it's not the
best way to implement you problem. But other times, the poylmorphic,
duck typing behavior of 'if x' allows you to make your problem much
easier, in a way a simple test can't. To deny this fact is to deny to
power of dynamic languages in general.
-Matt