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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4