[C++-sig] [c++-sig] Is it a BUG? boost.python makes doctest impossible to recursive test.

[Hans Meine]

Hi 甜瓜!

You wrote:
> inspect.isfunction(val) ALWAYS returns False, because the type of
> 'val' corresponding to 'func' in class C is:
> <Boost.Python.function object at 0x....>
Here, I am getting <type 'instancemethod'>, with MRO [<type 'instancemethod'>, 
<type 'object'>].

> Therefore, the strange type of the class' method exposed by
> boost.python suppresses the doctest to recursively discover __doc__.
> What should I do? Is is a bug for boost.python?
This relates to my recent postings on BPL and epydoc ("Better 
introspection/apidoc extraction support?" thread).  It would be really cool 
if the inspect module could be enhanced to work with boost::python.

AFAICS, for much functionality it would be needed to enhance boost::python, 
since much information is not even available.  For example, the signature of 
functions is not available - now there is a string representation in the 
docstrings (only not disabled), but it is impossible to parse in general, 
since values of default arguments can have any string representation.
A contrived example would be an object o with repr(o) == "1, foo = 23" which 
makes the parser believe that there's another argument, but there are many 
real-world cases where the repr() output does not allow creating an identical 
object, or not even recognizing the type.

In your case, I see two solutions: Enhancing the 'inspect' module to recognize 
boost::python functions or make BPL methods be instances of the right type.
But wait.. the latter already seems to be the case with 1.34.0beta:  
<type 'instancemethod'> is types.MethodType!
Consequently, inspect.ismethod() returns True, but inspect.isfunction() 
returns False.

However, I am getting <Boost.Python.function object at 0x....> for free 
functions (I thought your example was about the method C.func?):

In [11]: type(norm)
Out[11]: <type 'Boost.Python.function'>

In [12]: _.mro()
Out[12]: [<type 'Boost.Python.function'>, <type 'object'>]

Maybe Boost.Python.function could be derived from types.FunctionType?
(Probably not, otherwise it would have been done already.)

BTW: A good example for deriving from python types is numpy:
In [16]: numpy.float64.mro()
Out[16]:
[<type 'numpy.float64'>,
 <type 'numpy.floating'>,
 <type 'numpy.inexact'>,
 <type 'numpy.number'>,
 <type 'numpy.generic'>,
 <type 'float'>,
 <type 'object'>]

Ciao, /  /
     /--/
    /  / ANS