Martin v. L?wis wrote:
Why would you want to sub-class a function object?
* To provide methods on the object allowing OO-style API's for
That won't work. If you create a function through the def statement,
it will be of type function, not of a subclass thereof. So on all function
objects, your introspection methods won't be available.
It would certainly be required to have a base-class constructor. You'll
note, however, that this wasn't really an insurmountable problem for the
type meta-class ;) . Like that change, you need the system to support
the operation (i.e. call it) if you want syntactic support, but it's not
an impossible change.
BTW Even today, without support built into the system to call the
function-constructor when reading a source-file, you could still use it
within systems where run-time definition of classes is the norm, such as
embedded scripting systems (you call the function-type's constructor
whenever you want to create a new function).
The question then becomes, is it appropriate to allow the
Not unless accompanied with some other change to
conveniently create specialized function objects. One
proposal (originally proposed to create class methods) might work:
foo = SpecialFunction( 'foo', """
self.x = y
Sure, there's lots of problems with it (about equal to those with
"property" IMO), but the question of the *hook* to invoke the mechanism
is somewhat distinct from the mechanism itself, no? After all, we had
the "new" module for years before the functionality eventually migrated
to the base-type constructors.
This would create a function object first, then invoke the
callable enhanced_cleanup, which returns a modified (or
wrapped) object. However, if this extension were available,
specializing the function type is still not necessary, since
you could just as well create wrapper objects in all
usage scenarios you have given.
See notes regarding wrapping versus inheriting in the original post. My
"arguments" aren't necessarily compelling, but the trend does appear to
be toward sub-classable base-types.
Which comes back to Tim's post, suggesting that a volunteer creating a
sub-classable version of the function object would be sufficient to
introduce such a thing to the core.
I suspect any volunteer would notice quickly that this is not sufficient.
I'd guess it would depend on the volunteer's purposes, and whether
they're trying to get the syntactic operation you want ;) working :) .
I find the meta-type constructor's syntactic sugar gets in the way about
as much as it helps (you wind up having to muck about in the class'
namespace to define named arguments which you then need to decide
whether to include in the final class or not).
The simple call approach works. It lets you define arguments (how do you
do that with the def x()[a,b,c] syntactic construct, for instance), it
is familiar and readily understood (no new syntax required, you can
immediately see that you're getting something back from a
constructor/function, there's no magic invocation going on). It's not
convenient for replacing every function/method in a file, but neither
would the  syntax.
It might be neat to see def and class (maybe even if and else ;)
(just kidding :) )) decommisioned as keywords and a syntactic
construct created something like this:
callable name [ ( args, named ) ]:
creating pseudo-code like this:
name = callable( name, suite-code-string, argumentDescriptions )
with def and class being objects (a new function meta-type, and the
type meta-type (or rather, a sub-class or factory to generate
appropriately new/old style classes by executing suite-code in a
dictionary then calling the current constructor)) which obey the
Even cooler, you might rework the parser so that the suites are
passed to their constructors w/out going through the parser's
syntactic check. You then have a hook for such things as Pyrex to
embed their functions directly in the Python code. Of course,
that's probably a little *too* flexible if we're going to maintain
some level of "Python-1.5-ness" in the core :) .
Have fun, stay loose, become one with the universe,
Mike C. Fletcher
Designer, VR Plumber, Coderhttp://members.rogers.com/mcfletch/