[C++-sig] [c++-sig] Is it a BUG? boost.python makes doctest impossible to recursive test.
meine at informatik.uni-hamburg.de
Mon Jun 11 10:55:59 CEST 2007
> 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'>,
> 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()
However, I am getting <Boost.Python.function object at 0x....> for free
functions (I thought your example was about the method C.func?):
In : type(norm)
Out: <type 'Boost.Python.function'>
In : _.mro()
Out: [<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 : numpy.float64.mro()
Ciao, / /
/ / ANS
More information about the Cplusplus-sig