tommy said that this would be the best place to ask
this question....
I'm trying to get functions wrapped via boost to show
up as builtin types so that pydoc includes them when
documenting the module containing them. Right now
boost python functions are created using a PyTypeObject
such that when inspect.isbuiltin does:
return isinstance(object, types.BuiltinFunctionType)
isintance returns 0.
Initially I had just modified a local pydoc to document all
functions with unknown source modules (since the module can't
be deduced from non-python functions), but I figured that
the right fix was to get boost::python functions to correctly
show up as builtins, so I tried setting PyCFunction_Type as the
boost function type object's tp_base, which worked fine for me
using linux on amd64, but when my patch was tried out on other
platforms, it ran into regression test failures:
http://mail.python.org/pipermail/c++-sig/2005-February/008545.html
So I have some questions:
Should boost::python functions be modified in some way to show
up as builtin function types or is the right fix really to patch
pydoc?
Is PyCFunction_Type intended to be subclassable? I noticed that
it does not have Py_TPFLAGS_BASETYPE set in its tp_flags. Also,
PyCFunction_Type has Py_TPFLAGS_HAVE_GC, and as the assertion failures
in the testsuite seemed to be centered around object allocation/
garbage collection, so is there something related to subclassing a
gc-aware class that needs to be happening (currently the boost type
object doesn't support garbage collection).
If subclassing PyCFunction_Type isn't the right way to make these
functions be considered as builtin functions, what is?
-nick
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
