Update PEP 3146: discuss impact on other forks/branches; clarify language on PyPy; resolve open issues; clarify qualifications for final merger.

pep-3146.txt

@@ -49,7 +49,7 @@ We seek the following from the BDFL:
 - Permission to continue working on the just-in-time compiler in the CPython
   source tree.
 - Permission to eventually merge the just-in-time compiler into the ``py3k``
-  branch once all blocking issues have been addressed.
+  branch once all blocking issues [#us-punchlist]_ have been addressed.
 - A pony.
 
 
@@ -195,9 +195,11 @@ which we considered, but found unsatisfactory.
   no plans for 64-bit support; supports x86 only; very difficult to maintain;
   incompatible with SSE2 optimized code due to alignment issues.
 - *PyPy*: PyPy [#pypy]_ has good performance on numerical code, but is slower
-  than Unladen Swallow on non-numerical workloads. PyPy only supports 32-bit
+  than Unladen Swallow on some workloads. Migration of large applications from 
-  x86 code generation. It has poor support for CPython extension modules,
+  CPython to PyPy would be prohibitively expensive: PyPy's JIT compiler supports 
-  making migration for large applications prohibitively expensive.
+  only 32-bit x86 code generation; important modules, such as MySQLdb and 
+  pycrypto do not build against PyPy; PyPy does not offer an embedding API, much 
+  less the same API as CPython.
 - *PyV8*: PyV8 [#pyv8]_ is an alpha-stage experimental Python-to-JavaScript
   compiler that runs on top of V8. PyV8 does not implement the whole Python
   language, and has no support for CPython extension modules.
@@ -655,6 +657,24 @@ While Unladen Swallow is source-compatible with CPython 2.6.4, it is not
 binary compatible. C extension modules compiled against one will need to be
 recompiled to work with the other.
 
+The merger of Unladen Swallow should have minimal impact on long-lived
+CPython optimization branches like WPython. WPython [#wpython]_ and Unladen
+Swallow are largely orthogonal, and there is no technical reason why both
+could not be merged into CPython. The changes needed to make WPython
+compatible with a JIT-enhanced version of CPython should be minimal
+[#us-wpython-compat]_. The same should be true for other CPython optimization
+projects (for example, [#asher-rotem]_).
+
+Invasive forks of CPython such as Stackless Python [#stackless]_ are more
+challenging to support. Since Stackless is highly unlikely to be merged into
+CPython [#stackless-merger]_ and an increased maintenance burden is part and
+parcel of any fork, we consider compatibility with Stackless to be relatively
+low-priority. JIT-compiled stack frames use the C stack, so Stackless should
+be able to treat them the same as it treats calls through extension modules.
+If that turns out to be unacceptable, Stackless could either remove the JIT
+compiler or improve JIT code generation to better support heap-based stack
+frames [#llvm-heap-frames]_, [#llvm-heap-frames-disc]_.
+
 
 Platform Support
 ================
@@ -847,7 +867,10 @@ Lowlights:
 
 - Developers must know two related languages, C and C++ to work on the full
   range of CPython's internals.
-- A C++ style guide will need to be developed and enforced. See `Open Issues`_.
+- A C++ style guide will need to be developed and enforced. PEP 7 will be
+  extended [#pep7-cpp]_ to encompass C++ by taking the relevant parts of
+  the C++ style guides from Unladen Swallow [#us-styleguide]_, LLVM
+  [#llvm-styleguide]_ and Google [#google-styleguide]_.
 - Different C++ compilers emit different ABIs; this can cause problems if
   CPython is compiled with one C++ compiler and extensions modules are compiled
   with a different C++ compiler.
@@ -989,10 +1012,12 @@ We believe this approach will be minimally disruptive to the 3.2 or 3.3 release
 process while we iron out any remaining issues blocking final merger into
 ``py3k``. Unladen Swallow maintains a punchlist of known issues needed before
 final merger [#us-punchlist]_, which includes all problems mentioned in this
-PEP; we trust the CPython community will have its own concerns.
+PEP; we trust the CPython community will have its own concerns. This punchlist
+is not static; other issues may emerge in the future that will block final
+merger into the ``py3k`` branch.
 
-See the `Open Issues`_ section for questions about code review policy for the
+Changes will be committed directly to the ``py3k-jit`` branch, with only large,
-``py3k-jit`` branch.
+tricky or controversial changes sent for pre-commit code review.
 
 
 Contingency Plans
@@ -1058,31 +1083,6 @@ for dynamic languages that could and should be implemented in terms of Unladen
 Swallow's LLVM-based JIT compiler [#us-relevantpapers]_.
 
 
-Open Issues
-===========
-
-- *Code review policy for the ``py3k-jit`` branch.* How does the CPython
-  community want us to procede with respect to checkins on the ``py3k-jit``
-  branch? Pre-commit reviews? Post-commit reviews?
-
-  Unladen Swallow has enforced pre-commit reviews in our trunk, but we realize
-  this may lead to long review/checkin cycles in a purely-volunteer
-  organization. We would like a non-Google-affiliated member of the CPython
-  development team to review our work for correctness and compatibility, but we
-  realize this may not be possible for every commit.
-- *Prioritization of remaining issues.* We would like input from the CPython
-  development team on how to prioritize the remaining issues in the Unladen
-  Swallow codebase. Some issues like memory usage are obviously critical before
-  merger with ``py3k``, but others may fall into a "nice to have" category that
-  could be kept for resolution into a future CPython 3.x release.
-
-- *Create a C++ style guide.* Should PEP 7 be extended to include C++, or
-  should a separate C++ style PEP be created? Unladen Swallow maintains its own
-  style guide [#us-styleguide]_, which may serve as a starting point; the
-  Unladen Swallow style guide is based on both LLVM's [#llvm-styleguide]_ and
-  Google's [#google-styleguide]_ C++ style guides.
-
-
 Unladen Swallow Community
 =========================
 
@@ -1445,6 +1445,27 @@ References
 .. [#msvc-pgo]
    http://msdn.microsoft.com/en-us/library/e7k32f4k.aspx
 
+.. [#us-wpython-compat]
+   http://www.mail-archive.com/python-dev@python.org/msg44962.html
+
+.. [#asher-rotem]
+   http://portal.acm.org/citation.cfm?id=1534530.1534550
+
+.. [#stackless]
+   http://www.stackless.com/
+
+.. [#stackless-merger]
+   http://mail.python.org/pipermail/python-dev/2004-June/045165.html
+
+.. [#llvm-heap-frames]
+   http://www.nondot.org/sabre/LLVMNotes/ExplicitlyManagedStackFrames.txt
+
+.. [#llvm-heap-frames-disc]
+   http://old.nabble.com/LLVM-and-coroutines-microthreads-td23080883.html
+
+.. [#pep7-cpp]
+   http://www.mail-archive.com/python-dev@python.org/msg45544.html
+
 
 Copyright
 =========