[Python-checkins] r78267 - peps/trunk/pep-3146.txt

Sat Feb 20 23:02:19 CET 2010

Author: collin.winter
Date: Sat Feb 20 23:02:19 2010
New Revision: 78267
Log:
Update PEP 3146: discuss impact on other forks/branches; clarify language on PyPy; resolve open issues; clarify qualifications for final merger.
Modified:
 peps/trunk/pep-3146.txt
Modified: peps/trunk/pep-3146.txt
==============================================================================

--- peps/trunk/pep-3146.txt	(original)
+++ peps/trunk/pep-3146.txt	Sat Feb 20 23:02:19 2010
@@ -49,7 +49,7 @@
 - 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 @@
 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
- x86 code generation. It has poor support for CPython extension modules,
- making migration for large applications prohibitively expensive.
+ than Unladen Swallow on some workloads. Migration of large applications from 
+ CPython to PyPy would be prohibitively expensive: PyPy's JIT compiler supports 
+ 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 @@
 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 @@
 
 - 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 @@
 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
-``py3k-jit`` branch.
+Changes will be committed directly to the ``py3k-jit`` branch, with only large,
+tricky or controversial changes sent for pre-commit code review.
 
 
 Contingency Plans
@@ -1058,31 +1083,6 @@
 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 @@
 .. [#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
 =========
