Making extension modules play nice with help()?

Nicholas Bastin nick.bastin at gmail.com
Tue Feb 17 18:29:46 EST 2009


I've always provided doc strings through PyMethodDef in the past, without
paying much attention to what happens in help() - they print fine when you
just use the doc string.  However, in help, you end up with methods that
have an indeterminate signature.  We generally make doc strings that look
like:
"get_root_calls() -> [ptv.Call, ...]"
"Returns all root calls for transactions in the trace."

Which works fine if you just print get_root_calls().__doc__ or somesuch, but
works out quite lousy if you use help():

|  get_root_calls(...)
|      get_root_calls() -> [ptv.Call, ...]
|      Returns all root calls for transactions in the trace.

So we end up with the method signature twice - once from help(), which is
meaningless (assuming a non-empty argument list), and once from the doc
string, which is actually useful.  Is there any way to either a) teach the
proper method signature to help(), or b) override it.

Also, while PyMethodDef has a nice place to put a doc string,
PyMappingMethods and tp_iter have no such place, and so we end up with
things like:

 |  __getitem__(...)
 |      x.__getitem__(y) <==> x[y]
 |
 |  __iter__(...)
 |      x.__iter__() <==> iter(x)

Which is decidedly unhelpful.  Can I grab the Type after it has been readied
and replace some attributes somewhere to put new strings in these places?

Of course, I can always cover the C extension module in a thin veneer of
python, but that starts to become a significant performance problem (not to
mention a maintenance nightmare).

--
Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20090217/062517b4/attachment.html>


More information about the Python-list mailing list