module not callable - why not?

[John Roth]

"Diez B. Roggisch" <deetsNOSPAM at web.de> wrote in message
news:c56jph$rrk$05$1 at news.t-online.com...
> Hi,
>
> I just thought about creating a module for quaternions (as an personal
> exercise, so I'm not after pointers to classlibs here).
>
> Now usually I'd create a file called "quaternion.py", define my quaternion
> class in there and then import and create an instance like this:
>
> import quaternion
>
> q = quaternion.quaternion()
>
> Thats a lot to type. doing a
>
> from quaternion import quaternion
>
> would solve that - but AFAIK thats considered bad for some reasons.

I don't know why that's bad. Its fairly common in fact.
What's usually bad is "from foobar import *" which loads
your module namespace with a bunch of identifiers that
are not documented in the source of that module, and that
may change if the imported module changes.

In fact, I'd probably do: "from quaternion import quaternion as q"
to minimize typing later.

> Now I thought about defining a __call__ operator at module level to allow
> this:
>
> import quaternion
>
> q = quaternion()
>
>
> where the call looks like this:
>
> def __call__(*a, *kw):
>     return quaternion()
>
> But that doesn't work.
>
> Now my question is: Is there a way to make a module callable that way? And
> wouldn't it make sense to allow the implementation of a call operator on
> module level?

No, and probably not.

There's no really earthshaking reason why a module object
couldn't be a callable, and I suspect it would be rather simple
to do. However, it would add some complexity to the model,
and IMO your use case isn't compelling enough.

Other people may disagree with me on that, though.

John Roth

> -- 
> Regards,
>
> Diez B. Roggisch