type function does not subtype

[Martin v. Löwis]

> Why would you want to sub-class a function object?
>
>     * To provide methods on the object allowing OO-style API's for
>       introspection?

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.

>     * Experimenting with meta-programming mechanisms

Same counter-argument: How do you create such specialized
function objects?

> The question then becomes, is it appropriate to allow the
> sub-classing approach?

Not unless accompanied with some other change to
conveniently create specialized function objects. One
proposal (originally proposed to create class methods) might work:

def foo(args)[enhanced_cleanup]:
   code

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.

> 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.

Regards,
Martin