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. regards.