Thomas Gellekum writes:
> You mean as separate modules like
>
> import curses
> import panel
Or better yet:
import curses
import curses.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[].
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
for the use of the panel (forms, ..., etc.) bindings, and simply
initialize them to NULL (or whatever) for newly created windows.
> Also, the curses.panel_{above,below}() wrappers need access to the
> list_of_panels via find_po().
There's no reason that underlying utilities can't be provided by
_curses using a CObject. The Extending & Embedding manual has a
section on using CObjects to provide a C API to a module without
having to link to it directly.
> That's easy. The problem is that we want to extend those basic objects
> in _curses.
Again, I'm curious about the necessity of this. I suspect it can be
avoided. I think the approach I've hinted at above will allow you to
avoid this, and will allow the panel (forms, ...) support to be added
simply by adding additional modules as they are written and the
underlying libraries are installed on the host.
I know the question of including these modules in the core
distribution has come up before, but the resurgence in interest in
these makes me want to bring it up again: Does the curses package
(and the associated C extension(s)) belong in the standard library, or
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.
-Fred
--
Fred L. Drake, Jr. <fdrake at acm.org>
PythonLabs at Digital Creations
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