If you define a type in C and add it to a module's 
dictionary, it will not be displayed by pydoc.  Now 
that calling such types can serve as the constructor 
for the type's instances, I think pydoc should ensure 
that the types are displayed.

Pydoc sees such types as classes because 
inspect.isclass returns true for them:

def isclass(object):
    return isinstance(object, types.ClassType) or  
        hasattr(object, '__bases__')

(The above succeeds for because C types have a 
__bases__ attribute).  However, when pydoc checks to 
see if the type/class is defined in the module being 
documented, it uses the type's __module__ attribute to 
look up the module in sys.modules.  By default, C 
types always return "__builtin__" as their __module__, 
so pydoc concludes the type was actually declared in 
the __builtin__ module and does not show it.

(Perhaps this is really a documentation bug -- there 
does not seem to be anything indicating that types 
which wish to expose themselves to pydoc should 
redefine the __module__ attribute.)

Logged In: YES 
user_id=11105

As the most recent documentation (which is just a few days 
old) shows, it's a bug in the extensions module IMO ;-).
You have to use "<module>.<name>" as the tp_name slot in 
the extension type, and __module__ will automatically be 
set. pydoc then also documents this type.

http://starship.python.net/crew/theller/pyhelp.cgi?
keyword=tp_name&version=devel

Logged In: YES 
user_id=33168

Ping, is this a pydoc problem?

Logged In: YES 
user_id=86307

FWIW, I agree with Thomas Heller that this was really a bug 
in the C type: it did not have a properly formed tp_name.  As 
far as I am concerned, this report should be considered "not a 
bug" and closed.  (As the original poster, am I allowed to 
close it?)

Logged In: YES 
user_id=33168

Greg, your wish is my command.  Closed.  :-)

I think you can close the bug, but I'm not sure.  SF is
flaky about some things.