[Python-checkins] peps: Explicitly mention accelerator modules can be a subset of functionality.

brett.cannon python-checkins at python.org
Wed Apr 6 19:05:59 CEST 2011


http://hg.python.org/peps/rev/28f8ebde4dc8
changeset:   3861:28f8ebde4dc8
user:        Brett Cannon <brett at python.org>
date:        Wed Apr 06 10:05:50 2011 -0700
summary:
  Explicitly mention accelerator modules can be a subset of functionality.

files:
  pep-0399.txt |  30 ++++++++++++++++--------------
  1 files changed, 16 insertions(+), 14 deletions(-)


diff --git a/pep-0399.txt b/pep-0399.txt
--- a/pep-0399.txt
+++ b/pep-0399.txt
@@ -14,12 +14,13 @@
 ========
 
 The Python standard library under CPython contains various instances
-of modules implemented in both pure Python and C. This PEP requires
-that in these instances that both the Python and C code *must* be
-semantically identical (except in cases where implementation details
-of a VM prevents it entirely). It is also required that new C-based
-modules lacking a pure Python equivalent implementation get special
-permissions to be added to the standard library.
+of modules implemented in both pure Python and C (either entirely or
+partially). This PEP requires that in these instances that both the
+Python and C code *must* be semantically identical (except in cases
+where implementation details of a VM prevents it entirely). It is also
+required that new C-based modules lacking a pure Python equivalent
+implementation get special permissions to be added to the standard
+library.
 
 
 Rationale
@@ -33,14 +34,15 @@
 used in Java applications.
 
 A problem all of the VMs other than CPython face is handling modules
-from the standard library that are implemented in C. Since they do not
-typically support the entire `C API of Python`_ they are unable to use
-the code used to create the module. Often times this leads these other
-VMs to either re-implement the modules in pure Python or in the
-programming language used to implement the VM (e.g., in C# for
-IronPython). This duplication of effort between CPython, PyPy, Jython,
-and IronPython is extremely unfortunate as implementing a module *at
-least* in pure Python would help mitigate this duplicate effort.
+from the standard library that are implemented (to some extent) in C.
+Since they do not typically support the entire `C API of Python`_ they
+are unable to use the code used to create the module. Often times this
+leads these other VMs to either re-implement the modules in pure
+Python or in the programming language used to implement the VM
+(e.g., in C# for IronPython). This duplication of effort between
+CPython, PyPy, Jython, and IronPython is extremely unfortunate as
+implementing a module *at least* in pure Python would help mitigate
+this duplicate effort.
 
 The purpose of this PEP is to minimize this duplicate effort by
 mandating that all new modules added to Python's standard library

-- 
Repository URL: http://hg.python.org/peps


More information about the Python-checkins mailing list