[wxPython] Grokking wxPython: Doc Strings, and parameters listed in method wrappers.

My apologies to Robin for calling wxPython a "byzantine morass". <Grin>

I am calmer now. I now have some constructive and possibly useful questions
and ideas.

--TOPIC1: __doc__ Strings--

Who would be interested in having Doc strings added to most of the basic
methods (starting of course with wxFrame and wxButton and all the trival
stuff, and then to each widget and class which a beginning Python user would
touch). See docstrings-example.jpg, attached.

Here is a sample docstring I wrote as an example for the class wxFrame,which
should appear when you type "wxFrame(" in something like IDLE. The idea is
for the first line of the comment, which is all that appears in IDLE, to be
a memory-jog of parameter names and reasonable sample values:

Here is the snippet of modified file "c:\python21\wxPython\frames.py":

class wxFrame(wxFramePtr):
     """wxFrame(parent=None, id=-1, title='Window Title'):moveable sizeable
frame window
            Create new wxFrame object, set parent (owner), window id, and
            window title (string)
        ARGUMENTS:
            pos:
                (-1, -1) indicates a default position.
            size:
                (-1, -1) indicates a default size.
            style:
                see ::WXFRAME_STYLES::
            name:
                The name of the window. Associate Motif resource
                values for individual windows.
         EXAMPLE:
            myWin = wxFrame(None,-1,'My
Window',style=wxDEFAULT_FRAME_STYLE|)
            myWin.Show(true)
         SEE ALSO:
             ::WXFRAME_STYLES:: Style options for wxFrame
    """

Anyways, yes, I KNOW that frames.py is semi-automatically generated by SWIG,
so my questions
would be (a) is it better to modify the SWIG generation process to grab
these comments from a database
and insert them during SWIG generation, or (b) would it be better if I try
to use the "parser" module to
provide an "after the fact insertion" of these doc strings, for those who
want them, and we leave the default swig generated code alone.

Also, interested in anyone's opinion on the following tradeoffs:
        (1) Size of doc-strings: One liners? One to five liners? Five to 20
Liners?
        (3) How about if the doc-strings are One Liners but they end in a
unique identifier like this:

class wxFrame(wxFramePtr):
     """wxFrame(parent=None, id=-1, title='Window Title'):moveable sizeable
frame window ::WX01234::"

Then, in a tool, such as a modified IDLE, or in Boa Constructor, we add a
clickable link or live-help window pane, that pops up a more thorough
document on that method, probably generated in a wxHtml window.

What do people think of this?

It is important enough to me to have this, that I would contribute my time
and efforts to building such a database of help topic contents, which might
help people to learn wxPython by the more typical Python introspection
methods.

--TOPIC 2: Can we get SWIG to Declare The Parameter Names? [ def
method(self,*_args,**_kwargs) ]

Can SWIG generate, instead of "*_args,**_kwargs", an actual list of
parameter names and default parameter values? For instance:

class wxFrame(wxFramePtr):
    def __init__(self,parent,id,title ... ):
        ...

Maybe it would be less annoying if IDLE and other GUIS just plain didnt show
the supremely unhelpful "(...,***)" as a code completion hint at all. If
there was a Doc String instead, I am sure most people can learn to live with
the output shown in the JPG attached below, where at least they get
something to jog
their memory with.

Constructively-Yrs,

Warren Postma

My apologies to Robin for calling wxPython a "byzantine morass". <Grin>

Accepted.

I am calmer now. I now have some constructive and possibly useful

questions

and ideas.

--TOPIC1: __doc__ Strings--

Anyways, yes, I KNOW that frames.py is semi-automatically generated by

SWIG,

so my questions
would be (a) is it better to modify the SWIG generation process to grab
these comments from a database
and insert them during SWIG generation, or (b) would it be better if I try
to use the "parser" module to
provide an "after the fact insertion" of these doc strings, for those who
want them, and we leave the default swig generated code alone.

I'm already working on this, although I'm not to the point yet of having to
decide the (a) or (b) yet, probably over the holidays if I can get some
quiet time. Riaan has done some work similar to a combination of (a) and
(b) already that he has shared with me, but I am leaning more towards (a)
but with the content in the code, not a DB. (That's been tried already.)

Also, interested in anyone's opinion on the following tradeoffs:
        (1) Size of doc-strings: One liners? One to five liners? Five to

20

Liners?

They will be full reference documentation that can be run through something
like HappyDoc or pydoc to generate a standalone HTML (or other) reference
guide. I expect that I'll have a switch so only the first line or two will
end up in the released doc-strings, but the whole thing will be there for
the doc generator.

--TOPIC 2: Can we get SWIG to Declare The Parameter Names? [ def
method(self,*_args,**_kwargs) ]

Can SWIG generate, instead of "*_args,**_kwargs", an actual list of
parameter names and default parameter values? For instance:

class wxFrame(wxFramePtr):
    def __init__(self,parent,id,title ... ):
        ...

Yes, but you lose the ability to specify keyword args.

···

--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters?
http://wxPython.org Relax with wxPython!

Robin said:

> --TOPIC 2: Can we get SWIG to Declare The Parameter Names? [ def
> method(self,*_args,**_kwargs) ]
>
> Can SWIG generate, instead of "*_args,**_kwargs", an actual list of
> parameter names and default parameter values? For instance:
>
> class wxFrame(wxFramePtr):
> def __init__(self,parent,id,title ... ):
> ...
>

Yes, but you lose the ability to specify keyword args.

How so? Do you mean additional keyword arguments, or that none of the
arguments could be specified in keyword format, only positional? I'm not
that familiar with SWIG and what it can/cannot do.

···

---
Patrick K. O'Brien
Orbtech.com - Your Source For Python Development Services
Phone: 314-963-3206