Update PEP 3146: discuss impact on other forks/branches; clarify language on PyPy; resolve open issues; clarify qualifications for final merger.
This commit is contained in:
Collin Winter
parent
e5f8d610aa
commit
d0b2f996c7
87
pep-3146.txt
87
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
|
||||
=========
|
||||
|
|
|
|||
Loading…
Reference in New Issue