[pypy-svn] r49796 - pypy/extradoc/planning/roadmap

[jacob at codespeak.net]

Author: jacob
Date: Fri Dec 14 18:16:34 2007
New Revision: 49796

Added:
   pypy/extradoc/planning/roadmap/
   pypy/extradoc/planning/roadmap/cpython_replacement.txt
Log:
New roadmap file for becoming a viable replacement to CPython.

Added: pypy/extradoc/planning/roadmap/cpython_replacement.txt
==============================================================================
--- (empty file)
+++ pypy/extradoc/planning/roadmap/cpython_replacement.txt	Fri Dec 14 18:16:34 2007
@@ -0,0 +1,119 @@
+
+
+Refactor the JIT
+================
+
+The JIT is the result of programming under severe time pressure. This
+means that the existing JIT framework needs a fair bit of cleanup and
+restructuring. Armin also has some ideas for a refactoring based on an
+interpreter, rather than annotated graphs. 
+XXX maybe phrase this a bit more clearly.
+
+Add optimizations to the JIT
+============================
+
+A base set of optimizations include common operations on floats and
+strings as well as general call optimization. Fixing bugs in the
+current JIT implementation is also needed.
+
+Separate compilation
+====================
+
+To make porting third party modules reasonable, it should not be necessary
+to recompile all of PyPy every time you want to integrate a new extension
+module. This requires supporting separate compilation.
+
+Support a tool like Swig or Boost
+=================================
+
+To make it simpler to integrate C extensions with PyPy, we should support
+at least one tool that is already in use in the Python community.
+
+Google uses Swig heavily, so in a scenario where Google pays for some
+development, it would be natural to do Swig. Once PyPy gets traction
+we expect proponents of other tools to make their own ports.
+
+In addition to Swig, a PyPy version of ctypes should be implemented.
+An attempt to build a layer on top of the existing ctypes
+implementation for CPython has failed. Ctypes was not written with
+this kind of reuse in mind, and it would be harder to change it
+than to make an RPython implementation from scratch.
+
+XXX Some example use case needed here.
+
+Port more modules to rffi style
+===============================
+
+Some standard modules written in C have already been ported to the
+rffi style, but more remain.
+XXX Flesh out with some more details. Examples for example.
+
+Move modules from app to interpreter level
+==========================================
+
+Some modules are implemented in Python at application level. For
+preformance reasons, they should be implemented at interpreter level.
+
+XXX Which ones?
+
+Write new modules
+=================
+
+There are still some modules in the standard library that need writing
+before PyPy is a reasonable replacement for CPython. Exactly which
+ones needs some investigation.
+XXX Flesh out with some more details. Examples for example.
+
+Hand optimizations
+==================
+
+There are still some hand optimizations of the Python interpreter that
+are well worth doing, since they can be expected to yield significant
+performance improvements. For instance, some of our mircobenchmarks
+show particularly poor performance in some areas. The use of better
+algorithms should improve our performance numbers significantly for
+some of the benchmarks.
+
+Parser cleanup
+==============
+
+The parser is in a rather sorry state. Making it support various
+versions of Python is currently a rather nasty job. It needs replacing
+with a more robust design. The estimates for this are probably too low,
+since they were based on the idea of improving the existing parser.
+Subsequent attempts to improve the parser have prompted the idea of
+a rewrite. In the parser work, there is also time needed to upgrade
+the interpreter to handle all of Python 2.5.
+
+Multi-platform support
+======================
+
+In order to be a viable alternative to CPython, PyPy needs to be
+tested and run cleanly on more platforms than it currently does. Amd64
+with Linux is probably the most urgent one, but there are probably
+others that have some problems.
+
+It probably makes sense to put this item off until we are closer to
+having a production ready system for the i386. We also have a possible
+volunteer effort under way. It remains to be seen if it takes off.
+
+Support a GUI
+=============
+
+One of the C extension modules that we need to have in order to get
+traction is support for one of the multi-platform GUI toolkits. The
+choice is probably between Qt and wxWindows, with Tkinter as a
+possible third. Someone with more understanding of the Python
+community than us should make the pick. Which one would bring more
+users to PyPy? Would any one of them prompt proponents of other
+GUI toolkits to make their own ports?
+
+Third party module support
+==========================
+
+There are some third party modules that would bring early adopters to
+PyPy. They would also serve as code coverage cases. Our time estimate
+is a guess on how much time we would need to spend to get enough
+traction in the community. Exactly what modules to support needs to
+be determined after some of the infrastructure in other tasks is
+in place.