Carl Banks wrote:
On Aug 1, 8:49 am, Matthew Fitzgibbons <[EMAIL PROTECTED]> wrote:
Carl Banks wrote:
On Jul 31, 11:44 pm, Carl Banks <[EMAIL PROTECTED]> wrote:
[snip excellent explanation of why it's hard to for "if x" to be
extensively polymorphic]
By the way, one thing I forgot to mention is Matt Fitzgibbons' filter
example.
As I said, it's hard to write code that works for both numeric and
container types because they share so few methods. However, sometimes
you don't know ahead of time what methods are used! When you're doing
functional programming you might pass in a method that calls the
appropriate method, like so:
def apply_if_true(func,x):
if x:
func(x)
I find myself doing things like this surprisingly often. All you've done
is move the decision as to what function is applied to x elsewhere. Like
a factory, for example. I could see using something like this where func
prepares object x to be inserted into a database, and you want to make
sure x is meaningful first.
def add_to_db(prep_func, x):
if x:
entry = prep_func(x)
add_to_db(entry)
'if x' strikes me as better for this case because you might want to
accept a non-empty list (or some other objects) but reject non-empty
lists. 'if x is None' would not work. It still may be susceptible to the
empty iterator problem, depending on what prep_func does.
What if what you consider to be "meaningful" doesn't happen to
coincide with what Python considers to be "something". For instance,
what if being non-negative is what makes an integer meaningful? You
can't use "if x" for that. What if any list, including an empty one,
is meaningful, but you want to indicate the possibility of an
unmeaningful value by passing None? You can't use "if x" for that.
So, you might address this issue by doing something like this:
def add_to_db(prep_func, is_meaningful, x):
if is_meaningful(x):
entry = prep_func(x)
add_to_db(entry
But if you do that, what has the polymorphism of "if x" gained you?
The thing it gained for you before is not having to pass in a
condition: whether x was a sequence, number, or whatever, the same
condition could be used, and thus you avoided considerable
complexity. But if you have to perform tests for which the implicit
boolean doesn't work, that complexity has to be added to the code
anyway.
Of course. If a chunk of code already does what you want it to, then you
can use it. Otherwise you have to do something different. I was just
pointing out that 'if x' often does what I want it to. Sometimes it
doesn't, so I do something different.
That matters in the context of this discussion because it limits the
usefulness of the polymorphism of "if x" for this functional idiom:
"if x" only helps you if you have no need for tests that it can't
handle.
[snip]
Carl Banks
--
http://mail.python.org/mailman/listinfo/python-list
By this argument, all code is limiting. Obviously, no code can do what
it can't.
We're not getting anywhere; it's past time to kill this one off.
-Matt
--
http://mail.python.org/mailman/listinfo/python-list
