Hi pypy-dev, I'd like to suggest heading towards making PyPy's mixed C-ported modules more self-contained and not have it's implementation and initilization spread over several directories and code areas. IMO it's good that CPython has basically one C file that describes a Module's implementation. With Python we could make it a package so that we can still separate information like interp-level, app-level and low-level glue code but keep things more together and have it picked up via some more plugin-based scheme. The package scheme (probably based on the current mixed modules approach) should have a runtime interface and try to stay indepedent from the inner PyPy developments like where exactly things at low level are located. With "runtime interface" i mean that PyPy would automatically discover all modules in a given plugin/module directory by importing and querying them to get information the provided module, a description (docstring) and e.g. which ll-functions are provided and special annotations and what not. Oh, and "py.py --listmodules" should provide a full view of available modules (and modules included by the current defaults) so that you can pass that to --usemodules="x,y,z". This involves a bit of API design that we haven't done much for our internal stuff yet but i think it's about time to provide some nicer APIs and separate things. What do you think? A sprint topic? First write documentation and then implement? cheers, holger
Hi Holger, On Wed, Aug 31, 2005 at 08:45:04PM +0200, holger krekel wrote:
I'd like to suggest heading towards making PyPy's mixed C-ported modules more self-contained and not have it's implementation and initilization spread over several directories and code areas.
The 'thread' module is pretty much self-contained in this respect (I tried to keep it this way as much as possible), so I would like to hear more specifically what you think is still missing. The structure is: pypy/module/thread/ __init__.py interface app_*.py app-level stuff os_*.py interp-level stuff ('os' means using os threads) test/ tests for the above rpython/ exttable.py table of external functions (guides both the annotator and the rtyper) ll_thread.py the low-level functions (similar to rpython/module/ll_*.py) test/ rpython-level tests of external functions There is nothing at all specific to the thread module in pypy/annotator or in pypy/rpython. However, for now, there is some C support code in pypy/translator/c/src/*.h; I didn't know exactly if it is a good idea to put even that in the pypy/module/thread package. Maybe it is. A bientot, Armin.
Hi Armin, On Thu, Sep 01, 2005 at 11:41 +0200, Armin Rigo wrote:
On Wed, Aug 31, 2005 at 08:45:04PM +0200, holger krekel wrote:
I'd like to suggest heading towards making PyPy's mixed C-ported modules more self-contained and not have it's implementation and initilization spread over several directories and code areas.
The 'thread' module is pretty much self-contained in this respect (I tried to keep it this way as much as possible), so I would like to hear more specifically what you think is still missing. The structure is:
pypy/module/thread/ __init__.py interface app_*.py app-level stuff os_*.py interp-level stuff ('os' means using os threads) test/ tests for the above rpython/ exttable.py table of external functions (guides both the annotator and the rtyper) ll_thread.py the low-level functions (similar to rpython/module/ll_*.py) test/ rpython-level tests of external functions
That looks good indeed but we are not using similar structures for most of the other mixed modules. Moreover, i am more interested in the "runtime" interface and decoupling module implementations from PyPy internals. For example, we could import all module/X's at root level and query the package (or plain module, even) for all neccessary info like lldefs, annotation info for external functions, etc. And the module files themselves should use a resonably stable and documented way to access the neccessary lltypes and friends. The idea is a bit to allow more people to work on porting C-modules conveniently and rather self-containedly (with good error messages for annotations that conflict with provided info in the exttable for example). cheers, holger
participants (3)
-
Armin Rigo -
holger krekel -
hpk＠trillke.net