[pypy-dev] plans for os and math

Samuele Pedroni 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 
example like:

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 
same effect
    fd = os.open(fname, flag, mode)
    return space.wrap(fd)

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 
lower priority).

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
and lib/_sio.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(...)[0] is OK at interpreter-level but os.stat(...).st_mode 
is not.

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 mailing list