type function does not subtype

[Mike C. Fletcher]

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

foo = SpecialFunction( 'foo', """
    self.x = y
    blah()
""")

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.
>
>Regards,
>Martin
>  
>
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.

Aside:

    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 ) ]:
            suite

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

    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

_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/