__call__ bad style? (was Re: Callable modules?)

[Alex Martelli]

Jonathan Hogg wrote:
        ...
> Another thread here discussed wrapping a function to provide 'before' and
> 'after' hooks. This is exactly the situation where I would use a __call__
> interface. Consider:

In that thread I showed how a closure provides a much simpler way
to perform the task as specified.  You seem to be arguing that __call__
is good because it makes it easy and natural to slide into "mission
creep", building components that are more complicated than needed, in
order to support extra features outside of the specifications.

If you think that supplying unrequested infrastructure is good, then
it's quite consistent that you like __call__.

I prefer simplicity.  "Do the simplest thing that can possibly work".
As you're showing, __call__ encourages tossing simplicity away.

It's peculiar that Python as it stands feels pretty good to people
with such totally divergent underlying philosophies of what software
development is all about.  I guess, in a way, that's a tribute to
Python's pragmaticity.  Warts such as N divergent ways to perform
a task (lambda, instance with __call__, closure, etc) will no doubt
remain due to both backwards compatibility constraints AND the
different constituencies pulling in opposite directions, helping
GvR to keep making his own decisions free from unbalanced "popular
opinion" push in one direction or another.  Good thing, too:-).


Alex