module __call__

[Dirck Blaskey]

Thomas Wouters <thomas at xs4all.net> wrote in message
news:20000419102700.M15664 at xs4all.nl...
> On Tue, Apr 18, 2000 at 04:23:43PM -0700, Dirck Blaskey wrote:
> > Fredrik Lundh <effbot at telia.com> wrote in message
> > news:7N4L4.497$wYl.191816704 at newsb.telia.net...
> > > Dirck Blaskey <dirck at pacbell.net> wrote:
> > > > ...Gee-Wouldn't-It-Be-Nice-If...
> > > >
> > > > modules could def __call__():
> > > >
> > > > so you could call a module, i.e.
> > > >
> > > >     import StringIO
> > > >     f = StringIO()
> > >
> > > and
> > >
> > > class myStringIO(StringIO):
> > >     ...
> > >
> > > would explode in your face.  lousy idea.
> >
> > ...
> > you have to
> >
> >     class myStringIO(StringIO.StringIO):
> >
> > as currently implemented.
>
> Yes, but 'f = StringIO()' doesn't work either, in that case. Fredrik's
> point, though a bit blunt, is that it would be confusing and thus unwise
to
> functionally separate
>
> f = StringIO()
>
> and
>
> class myStringIO(StringIO)
>
> ...

Thank you for the relevant explanation.
Actually, I was initially suprised to discover that
this feature wasn't already in the language.
If there was a 'module' class it would already work, but
I can't see any other benefit to implementing a 'module' class.

Personally, I don't think it would be confusing, because
I instantiate classes a lot more frequently than I subclass.
However, I can relate to the motivation to keep
magic tricks to a minimum.

(Restated:)
#=======
import mt

def x(s): print s

mt.__call__ = x
mt.__call__("ok")
mt("not ok")
#=======

still-adverb-less

d