PEP for an unrestricted __init__ ?!

[holger krekel]

On Fri, Apr 19, 2002 at 10:57:19AM -0700, Jeff Shannon wrote:
> In article <mailman.1019182657.12773.python-list at python.org>, 
> pyth at devel.trillke.net says...
> 
> > But __new__ or __init__ still restrict you to return instances
> > of their respective class? This does sound rather sane,
> > but i imagined some other uses for an unrestricted __init__ (or __new__)
> > such as making functions-objects a special case of classes:
> > 
> >    def func(args):
> >       "compute some stuff
> >       return result
> > and
> >    class func:
> >        def __init__(self, args):
> >           "compute some stuff"
> >           return result
> 
> Well, you can already accomplish something like what you are 
> asking for, by defining a __call__() method for the class.  That 
> lets class instances be used as callable objects -- using 
> function syntax on them.

right. but the version with __call__ makes functions and classes
still look quite different. (Please note that i am not complaining. 
python *does* provide powerful concepts for classes and functions.)

maybe it's just me but i often pass functions around. and sometimes
i don't want to set all parameters from one place but from different
places. E.g. by providing two out of four needed parameters
i get back a function which only takes two arguments (the missing ones).
Actually i have written a 15-line function wrapper (as a class :-)
that provides exactly this behaviour. The problem is that i *have* to write
func(allarguments) () for the case where i have all parameters
in once place. And i rather want this behaviour:
'if not enough arguments, return a function with the so-far available
arguments as presets. otherwise perform computation and return.'

Fortunately, after digging more into PEP 253 i am quite convinced
that guido's time machine really works: my proposed behaviour really
seems to be what the __new__ concept provides (at least in my quick
tests).

regards,

	holger