type function does not subtype

[Mike C. Fletcher]

Why would you want to sub-class a function object?

    * To provide methods on the object allowing OO-style API's for
      introspection?
          o retrieving arguments and/or variable names, defaults,
            presence of * or ** argument-sets
          o retrieving text of the function from source files
          o retrieving formatted "parameter" help text, or more detailed
            run-time help-text
          o retrieving "raised exception" information and/or
            caught-exception information
    * Experimenting with meta-programming mechanisms
          o automatically generating pre and/or post-condition checks
                + argument and/or return value types/interfaces/values
                + system-status checks (there is an open database
                  connection, there is a TCP/IP stack, or whatever)
          o providing a "restart" API for extremely long-running
            functions which have encountered exceptions
          o providing enhanced "cleanup" functionality for an entire
            class of functions which a framework may call if the
            function fails
    * To provide, for instance, a "script" function object defined in
      such a way that the function object stores the source code,
      provides pickling support, and is generally a first-class content
      object, but is a simple function object as far as the system is
      concerned (with no overhead for its call method, standard support
      in IDE's and documentation systems etceteras)

You can certainly do that stuff using wrapping, and it's certainly 
easier to do it that way today (given that the subclassing is 
impossible).  The question then becomes, is it appropriate to allow the 
sub-classing approach?

Recent changes in Python (i.e. 2.2+) have made the type-class split 
considerably less visible, with a trend toward using sub-classing of 
core objects as an acceptable and useful idiom.  Consistency and the 
principle of least surprise would suggest that having all of the 
primitive types sub-classable, where it doesn't negatively impact 
performance, is a good thing.  (It's also nice to allow systems such as 
the generic introspection systems to deal with the objects without 
needing explicit modification to support them (i.e., your functions 
still show up as functions in your IDE, you don't have them showing up 
as data attributes)).

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.

Enjoy,
Mike


Erik Max Francis wrote:

>Lenard Lindstrom wrote:
>
>  
>
>>Would someone please explain why subtyping of type 'function' is not
>>permitted in Python 2.3?
>>    
>>
>
>That would probably be best done by asking a counter question:  Why
>would you want to?
>  
>
_______________________________________
  Mike C. Fletcher
  Designer, VR Plumber, Coder
  http://members.rogers.com/mcfletch/