Callable modules?

[Chris Liechti]

Peter Hansen <peter at engcorp.com> wrote in
news:3D3C971E.D0386D7D at engcorp.com: 

> Paul Rubin wrote:
>> 
>> Stefan Schwarzer <sschwarzer at sschwarzer.net> writes:
>> > > Just to not have to say "foo.foo()" or "from foo import foo".
>> > > If the main purpose of the module is to provide one function, I
>> > > think it's cleaner to be able to import the module and call the
>> > > function without special tricks.
>> >
>> > I consider it cleaner to be explicit, and import the module and
>> > call its function. :-)
>> 
>> Does that reasoning not also apply to class instances?  Why should
>> class instances be callable through the __call__ method?
> 
> Because that's how you create an instance of the class (i.e. an
> object). 

no, no, read again... he already talks of instances, not classes. i.e. the 
__call__ method.

> If you have a reasonable parallel for all modules _in
> general_ then *that* would be the one reasonable case in which to use
> this scheme.  I can't think of a good one, myself.
> 
>> > How many actual cases do you know of where a module has a single
>> > function? Aren't they rare?
>> 
>> I've written several, there are several in the Python library, and
>> remember that it's not necessary for the module to have a single
>> function for a __call__ interface to be useful.  __call__ makes sense
>> if there's a most-important or most-frequently-used function in the
>> module.  It's ok if there are other functions too.
> 
> Although you can do as you wish, of course, I want to chime in
> with a "this is a really bad idea" and hope you don't follow through
> on it.  This is, even in the best case, going to make your code 
> less readable to anyone else.  It is also likely to cause
> maintainability problems because making the claim "but this module has
> only one function!" almost certainly means it will not stay that way
> forever. 

no need for such a restriction. just because an object has a __call__ 
method does not mean that it must not have any others. a module is an 
object after all, so there is realy no good reason to prevent it from 
having a __call__ method...

> Any time you find yourself going to a lot of effort to work around
> what feels like a small wart or syntactical ugliness (neither of which
> even apply in this case, IMHO) you should probably stop yourself and
> say "whoa, what was I thinking?" and do it the standard way.

yeah, its not realy needed. however having a __call__ function in modules 
would be nice for plugin systems, where a plugin == a module/file.py. it 
would allow to init the plugin by calling the module instead of defining an 
init() function or whatsoever.

considering the backwards incompatibility, it makes no sense to add a 
__call__ right now.

chris

-- 
Chris <cliechti at gmx.net>