[pypy-dev] Roadmap draft
holger at merlinux.de
Thu Dec 20 11:50:20 CET 2007
Dear Martijn, all,
I am aware that you have initiated and participated in various
successful open source communities and i know that you have experience
and advises to share. But the roadmap files are currently not
about release planning or strategies and ASFAIK no active developer
has asked for a public discussion about such topics.
I ask you and everybody to respect that. If neccessary
please only write brief mails.
FWIW, i think i understand and share your main point that
next-release goals do not neccessarily need to focus around
a PyPy's CPython-replacing interpreter. Btw, did you see that Anto
has added his drafts of a "goal_jython_ironpython_replacement.txt"?
best & cheers,
On Thu, Dec 20, 2007 at 10:04 +0100, Martijn Faassen wrote:
> The most important point I want to make is this one. The current
> discussion is about a roadmap towards CPython replacement (or other
> interpreter replacements). This is a *different* goal from having PyPy
> being useful in *some* production settings. The latter is a more modest
> goal. It also shifts the focus: instead of aiming for parity with
> CPython, you aim to be *better* than CPython at *some* things, while not
> having parity in other areas.
> So, you could have an interpreter that is not yet a full replacement for
> CPython being very useful for some tasks. This is where my primarily
> interest lies right now: it'll take a while before I can use a
> PyPy-derived interpreter instead of CPython for many tasks, but I'm
> interested in using it for at least *some* tasks.
> Being better at some things than existing interpreters in production
> will validate the project in the minds of many, and should increase the
> mindshare of PyPy tremendously and attract enough contributors to reach
> the final goal of being better at *everything*. I don't want to detract
> from that goal of parity with existing interpreters (and beyond). I
> don't want to take away from that. I just want to frame the discussion
> in a different light, and highlight other goals. You don't need parity
> in all respects in order to go beyond existing interpreters in some.
> I'll first note one way in which PyPy is already better than existing
> interpreters: flexibility. Unfortunately this benefit by itself is not
> going to be very useful in production itself. The idea is to exploit
> this flexibility. Flexibility is a goal of the project, but it's only a
> means, not a goal, of a production-interpreter project.
> As to the goal of being a CPython replacement, one important realisation
> is that you might in fact reach replacement of CPython through a
> completely other route than the one sketched out. Who is to say that a
> CPython replacement has to be run through a C compiler, after all? The
> only requirement is for it to run Python code. If that Python code runs
> on top of .NET or JVM, so be it, as long as it runs, right? Of course as
> an *end* goal you might want third-party library support, but you could
> get quite far as a replacement of CPython in other ways without covering
> So, what intermediate goals could you set that would make PyPy better
> than other interpreters in production settings? These are the main
> routes that I can see right now:
> You could aim for compliance with CPython (and library support) - but
> then actually replacing CPython is a goal you can't compete on soon!
> Your compliance will shine the most on other backends, like .NET or JVM,
> and the feature would be access to libraries on those platforms, so
> integration features would be the most important. Any performance or
> JIT-related task is less important on the near term, while integration
> tasks are most important.
> You could make compliance less important and aim for performance. In
> this case you could complete with CPython right away, even if your
> compliance and library support isn't perfect yet. You might only support
> Python 2.4 features and implement a limited set of libraries, and
> limited extension facilities, and still attract people. Performance and
> JIT related tasks are the most important.
> You could also target one specialist platform (some embedded
> architecture, or some dedicated VM architecture, like the Google Android
> platform). You could make PyPy work way better than any competition on
> that. (Multi)platform support beyond Linux, OS/X and Windows becomes way
> more important then.
> What your initial focus is would influence which tasks you focus on
> first a lot. I think this is important to keep in mind during the
> roadmap discussions. I'd of course also be curious to find out which
> ones you're most interested in as initial goals. Saying "all of them,
> right now" is not good enough. :)
> pypy-dev at codespeak.net
merlinux GmbH Steinbergstr. 42 31139 Hildesheim
http://merlinux.de tel +49 5121 20800 75 (fax 77)
More information about the Pypy-dev