[Python-Dev] Splitting up _cursesmodule

[Andrew Kuchling]

On Wed, Dec 13, 2000 at 10:19:01AM -0500, Fred L. Drake, Jr. wrote:
>  Do these new functions have to be methods on the window objects, or
>can they be functions in the new module that take a window as a
>parameter?  The underlying window object can certainly provide slots

Panels and windows have a 1-1 association, but they're separate
objects.  The window.new_panel function could become just a method
which takes a window as its first argument; it would only need the
TypeObject for PyCursesWindow, in order to do typechecking.

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

The list_of_panels is used only in the curses.panel module, so it
could be private to that module, since only panel-related functions
care about it.  

I'm ambivalent about the list_of_panels.  It's a linked list storing
(PyWindow, PyPanel) pairs.  Probably it should use a dictionary
instead of implementing a little list, just to reduce the amount of
code.

>does it make sense to spin out a distutils-based package?  I've no
>objection to them being in the core, but it seems that the release
>cycle may want to diverge from Python's.

Consensus seemed to be to leave it in; I'd have no objection to
removing it, but either course is fine with me.

So, I suggest we create _curses_panel.c, which would be available as
curses.panel.  (A panel.py module could then add any convenience
functions that are required.)

Thomas, do you want to work on this, or should I?

--amk