--- Nick Rasmussen <nick@ilm.com> wrote:
I'm running into a problem with functions at the module level not showing up in pydoc. The problem is that the type of the function object in the module is:
type(testfoo.foo) <type 'Boost.Python.function'>
Which isn't a sublcass of <type 'builtin_function_or_method'>
When pydoc walks the module it only documents routines that are either builtin (according to inspect.isbuiltin) or are objects whose module can be deduced via inspect.getmodule.
I modified function.cpp with:
--- libs/python/src/object/function.cpp.orig 2005-02-07 17:11:52.000066304 -0800 +++ libs/python/src/object/function.cpp 2005-02-07 16:55:24.000120507 -0800 @@ -608,7 +608,7 @@ 0, /* tp_methods */ 0, // func_memberlist, /* tp_members */ function_getsetlist, /* tp_getset */ - 0, /* tp_base */ + &PyCFunction_Type, /* tp_base */ 0, /* tp_dict */ function_descr_get, /* tp_descr_get */ 0, /* tp_descr_set */
and it seemed to fix it. Is this right, or is there a different way that functions should get exposed such that pydoc can understand them?
I applied this patch locally and tested it in 14 different configurations. It appears to work OK with Python 2.2, but leads to platform-specific fatal errors with Python 2.3 and 2.4 (Abort, Bus error, C assertions in Python, or plain wrong results). Here is the full damage: http://cci.lbl.gov/cctbx_build/show_error_summary.cgi?build_tag=2005_02_10_1... (This page will go away after a few days.) Using the exact same sources, but without the patch above, eliminates all errors. Before I knew about the Python 2.3 and 2.4 failures I asked David Abrahams regarding the patch. For the records:
With regards to this posting:
http://mail.python.org/pipermail/c++-sig/2005-February/008541.html
I've applied the patch locally. All the tests run fine. Can you think of any negative side-effects of applying the patch?
Well, I think it's probably benign.
It might mean that BPL function objects get bigger. Also, if something out there checks to see whether it's handling a PyCFunction and then manipulates the guts of the object on that basis, it might get unexpected results. I can't think of any other problems, but it's possible they're lurking. If I wanted to really know I'd have to go review what happens when you subclass a built-in type that way... and it's probably not documented, so that would mean reading the Python source.
We need a volunteer to do this research and to figure out what is wrong when using Python 2.3 and 2.4.
Also, for functions with overloads, only one of the docstrings is printed out. It looks like
void function::add_to_namespace( object const& name_space, char const* name_, object const& attribute, char const* doc)
just replaces the old doc string instead of appending the new one to the old.
Another case for a volunteer... Sorry that I cannot be more helpful. Cheers, Ralf __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail