[pypy-dev] plans for os and math
pedronis at strakt.com
Thu Jul 14 18:35:05 CEST 2005
This mail is an attempt to summarize a bit our current thinking and
plans for starting implementing
os and math modules functionality.
The idea is to implement them as mixed modules (like sys and __builtin__
are now), so to have, for starting,
a module/posix and module/math packages in module.
E.g. open would be implemented by posix at interpreter level, for
def open(w_fname, w_flag, w_mode=0777):
fname = space.str_w(w_fname)
flag = space.int_w(w_flag)
mode = space.int_w(w_mode)
# notice that an unwrap_spec attached to open could be used to the
fd = os.open(fname, flag, mode)
For now constants in os.* would be reimported by such a module. (So the
translation process and result
are platform dependent, we have ideas on how to fix this but those are
Similary math would be delegating to math at interpreter level. The
delegation is to get sort of placeholders
for translation and to be able to run on top of CPython.
We have started implementing in the toolchain from annotation to the
backends functionality such that the above
call to os.open at interpreter-level can be annotated and proper working
functionality can be supplied at the end
of the chain by the backend. (See rpython/extfunctable.py and the
contents of rpython/module). So sorting out platform
differences is intended to be a backend task.
The first things we need in os.* are the functions and constants
required by our app-level implementation of files in lib/_file.py
Functions like os.stat return tuple-like objects that have also named
attributes corresponding to the various fields.
The idea is that the calls at interpreter-level to such functions return
results that can only be numerically indexed,
so os.stat(...) is OK at interpreter-level but os.stat(...).st_mode
The mixed module would have OTOH to implement such result types
(possibly at app-level) and wrap in them the results of interpreter level
calls to placeholder functions.
More information about the Pypy-dev