[C++-sig] Python help() not showing imported Boost.Python-wrapped classes

[David Abrahams]

Doug Gregor <dgregor at cs.indiana.edu> writes:

> Python's interactive help is not showing classes exported using 
> Boost.Python. For instance, I have a module "_support" that uses 
> Boost.Python like this:
>
> BOOST_PYTHON_MODULE(_support)
> {
>    using boost::python::class_;
>    using boost::python::enum_;
>    using boost::python::init;
>
>    class_<point2d>("Point2D");
>    class_<point3d>("Point3D");
>    enum_<default_color_type>("Color");
>    def("distance", &point_2d_distance);
> }
>
> Now, that gets pulled into a package "bgl" that has this in its 
> __init__.py:
>
> 	from _support import *
>
> If I run help(bgl), something odd happens. Under the CLASSES heading, 
> the "Color" enum gets documented but Point2D and Point3D do not. Under 
> the FUNCTIONS heading, "distance" gets documented. \
>
> If I run help(bgl._support), I get Point2D and Point3D documented (in 
> the CLASSES section, of course) but neither "Color"  nor "distance".
>
> Ideally, the _support module would be invisible to the user, and all of 
> these classes and functions would show up when one uses help(bgl). Is 
> this possible?

>>> help(help)
Help on _Helper in module site object:

class _Helper(__builtin__.object)
 |  Define the built-in 'help'.
 |  This is a wrapper around pydoc.help (with a twist).
 
 <snip>

 http://www.python.org/doc/current/lib/module-pydoc.html

Getting pydoc to show the right things for Boost.Python has been an
ongoing struggle for some of us.  The cues pydoc takes from the
attributes in a module that it uses to decide what to document (and
how) are arcane and not well-understood.  I'd be happy if someone
wanted to take on the project of figuring out what was needed to make
everything come out right.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com