Callable modules?

[Alex Martelli]

Max M wrote:

> Alex Martelli wrote:
> 
> 
>> A respectable opinion.  Mine is just the reverse -- were it not
>> for backwards compatibility, I wouldn't mind losing __call__ in
>> instances.  A bound method can do it, and we could have a
>> _convention_ about how a "primary" method (if any) should be
>> named, just as we have for the 'self' argument.  It's all
>> theoretical anyway, __call__'s never going to go away in fact.
> 
> 
> I believe you mean something like:
> 
> class WithPrimary:
> 
>      def WithPrimary_primary(self):
>          # primary method due to naming conventions
>          pass
> 
> Why is this better than having an explicit __call__ method? Is it
> because of a dislike of the "__*__" methods in general?

It's because of a dislike of *language rules that don't carry their
own weight* in general.  The more rules a language has, the more
complicated it is.  Python is not complicated, but it could be
even simpler if it were possible to remove all of the deadwood,
and I include __call__ in that category.

I wouldn't mangle the methodname to include the classname -- no
use, and indeed some downsides.  Just pick one nice name and
use that, is my personal preference.

It WOULD mean you can't have an instance polymorphic to a
function any more, not exactly -- though *bound methods* of
that instance still would be.  Boo-hoo, what a loss.


> I must admit that I rarely use the __call__ method, but I have found it
> very convenient in some cases.

How is it more convenient to pass, say, object X, rather than
to pass bound method (e.g.) X.primary?  Take your example:

> The funny thing though is that I have found it most usefull when I need
> to set up a function in somehing like map(), sort(), filter() etc. where
> I need additional data passed to the visitor function, which these
> functions does not allow.

They don't allow for such extras because there's zero need for
them, of course -- closures, lambdas, bound methods and callable
instances provide FOUR ways to perform very similar tasks (and
currying, conceptually, a fifth, general way, though mostly you
have to implement it on top of one of the other four:-).


> So a "shortcomming" in Python is worked around by a strength, if you can
> say it like that.

I'm not sure I see any shortcoming.  Bound methods are a SERIOUS
strength, for sure.  Closures are VERY handy as an alternative
to bound methods -- you may save substantial boilerplate.  But
__call__ and lambda might perfectly well go without me shedding
any excessive numbers of tears.

They won't (go) of course, backwards compatibility if nothing
else, so this is a quite theoretical discussion:-).


Alex