From d0b2f996c77751ba6e901e921243309549cec5a2 Mon Sep 17 00:00:00 2001 From: Collin Winter Date: Sat, 20 Feb 2010 22:02:19 +0000 Subject: [PATCH] Update PEP 3146: discuss impact on other forks/branches; clarify language on PyPy; resolve open issues; clarify qualifications for final merger. --- pep-3146.txt | 87 ++++++++++++++++++++++++++++++++-------------------- 1 file changed, 54 insertions(+), 33 deletions(-) diff --git a/pep-3146.txt b/pep-3146.txt index eaa8299d6..e83880f4f 100644 --- a/pep-3146.txt +++ b/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 - 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 @@ 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 -``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 @@ 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 =========