[pypy-dev] Mixed modules for both PyPy and CPython

Armin Rigo arigo at tunes.org
Wed Apr 12 13:48:19 CEST 2006


Re-hi all,

A clarification on a point that caused confusion...

The purpose of the whole discussion was about how to have a "write-once,
run-everywhere" approach of developing an extension module a single time
and then compiling it for either CPython or PyPy.  This source code
should not need to know if it will be compiled for PyPy or CPython (or
even just run on top of the CPython interpreter for testing).

The two approaches I opposed are two ways to do that.

Some confusion came from the names of the two approaches, which I took
from IRC.  One approach is "single-source": this just means
"source-in-a-single-file", with wrapped objects and native values mixed
in the same source code.  (It's not in the sense "write a single time
the source"; both approaches are about this.)

By opposition, "mixed module" means "source-in-two-files", one running
at interp-level and one at app-level.  This is what we're doing in
pypy/module/*/{app,interp}_*.py.

Holger suggests to call "single-source" the whole approach of writing
once and running everywhere, which makes sense.  If we do so, then we
need better names for the two approaches.  What about "explicit" versus
"implicit" levels?  Mixed modules provide explicit level separation,
whereas the alternative is to rely on the annotator to separate the
levels.

I'd also like to point out that the latter -- implicit levels -- has a
kind of elegance to it that I like.  What I dislike, though, beyond the
fact that it would require yet another refactoring of PyPy's module
approach (and in a way that is quite unclear), is that it requires many
additional fragile rules and heuristics all over the flow objspace and
the annotator to get the "expected" separation of levels effects.  I'd
be happy to experiment more in that direction, but I believe that the
other direction's work is needed for now and won't be lost anyway.
Basically, we can still come back to this and think later about ways to
allow more implicit-level manipulations of objects.


A bientot,

Armin.



More information about the Pypy-dev mailing list