[Python-Dev] Splitting up _cursesmodule

[Thomas Gellekum]

Andrew Kuchling <akuchlin@mems-exchange.org> writes:

> [CC'ing Thomas Gellekum <tg@melaten.rwth-aachen.de>]
> 
> On Wed, Dec 13, 2000 at 01:24:01AM -0500, Fred L. Drake, Jr. wrote:
> >  Would it be reasonable to add panel support as a second extension
> >module?  Is there really a need for them to be in the same module,
> >since the panel library is a separate library?
> 
> Quite possibly, though the patch isn't structured that way.  The panel
> module will need access to the type object for the curses window
> object, so it'll have to ensure that _curses is already imported, but
> that's no problem.

You mean as separate modules like

import curses
import panel

? Hm. A panel object is associated with a window object, so it's
created from a window method. This means you'd need to add
window.new_panel() to PyCursesWindow_Methods[] and
curses.update_panels(), curses.panel_above() and curses.panel_below()
(or whatever they're called after we're through discussing this ;-))
to PyCurses_Methods[].

Also, the curses.panel_{above,below}() wrappers need access to the
list_of_panels via find_po().

> Thomas, do you feel capable of implementing it as a separate module,
> or should I work on it?

It's probably finished a lot sooner when you do it; OTOH, it would be
fun to try it. Let's carry this discussion a bit further.

>  Probably a _cursesmodule.h header will have
> to be created to make various definitions available to external
> users of the basic objects in _curses.

That's easy. The problem is that we want to extend those basic objects
in _curses.

>  (Bonus: this means that the
> menu and form libraries, if they ever get wrapped, can be separate
> modules, too.)

Sure, if we solve this for panel, the others are a SMOP. :-)

tg