[pypy-svn] rev 1293 - pypy/trunk/doc/funding

[lac at codespeak.net]

Author: lac
Date: Sun Sep 14 19:02:02 2003
New Revision: 1293

Added:
   pypy/trunk/doc/funding/B3.1_standards.txt
Log:
Will we effect standards


Added: pypy/trunk/doc/funding/B3.1_standards.txt
==============================================================================
--- (empty file)
+++ pypy/trunk/doc/funding/B3.1_standards.txt	Sun Sep 14 19:02:02 2003
@@ -0,0 +1,77 @@
+B.3.1   Contributions to standards: 
+
+Describe contributions to national or international standards which
+may be made by the project, if any.
+
+(Recommended length ­ one page)
+
+There are currently two implementations of Python in common use.  The
+first one, which we will call CPython, but which is what the world
+knows as Python, is a C implementation of the Python Programming
+langauge which compiles to its own virtual machine.  The second one is
+Jython, a pure-Python implementation which compiles to the Java
+virtual machine.  There is no ANSI standard or similar for Python.
+Right now the defacto standard for the programming language is
+'whatever CPython does'.  This is far from ideal, and questions arise,
+especially from the developers of Jython as to which CPython language
+behaviours are essential to the Python language itself, and which are
+mere accidents of this particular implementation.
+
+For example, the garbage-collection behavior of CPython is implemented
+by reference-counting ensuring that an object is finalized _as soon
+as_ the last reference to it goes away.  That would be extremely
+inconvenient (close to impossible) to implement on standard Java
+Virtual Machines, which have a deliberately under-specified garbage
+collector (it can collect anything it pleases whenever it pleases...).
+In this case, the Jython designers had to obtain an explicit ruling
+from Guido van Rossum, Python's designer -- who ruled that the
+behavior of CPython was 'accidental' in this case, and not intrinsic
+to the Python language specification.
+
+Guido van Rossum has expressed interest in giving PyPy the status of
+'implementation standard' (executable specification) of the Python
+programming language.  PyPy's ObjectSpaces flexibility will be crucial
+in distinguishing "accidental" from "designed-in" characteristics.
+
+(FIXME: I sent Guido mail asking for something quotable.  We will see
+if he replies.)
+
+In order to do this we will have to do something which is called
+'Submitting a PEP'.  A PEP - Python Enhancement Proposal - is a design
+document providing information to the Python community, or describing
+a new feature for Python.  There are two kinds of PEPs. A Standards
+Track PEP describes a new feature or implementation for Python. An
+Informational PEP describes a Python design issue, or provides general
+guidelines or information to the Python community, but does not
+propose a new feature.  If we proposed to make PyPy the reference
+standard of the Python language, we would, obviously, have to submit a
+Standards Track PEP.
+
+PEP authors are responsible for collecting community feedback on a PEP
+before submitting it for review. A PEP that has not been discussed on
+python-list at python.org and/or python-dev at python.org will not be
+accepted.  After the authors believe that the PEP is ready, they must
+inform the PEP editors (currently Barry Warsaw and David Goodger) that
+it is ready for review.
+ 
+PEPs are reviewed by Guido van Rossum, the language author, and his chosen 
+consultants, who may accept or reject a PEP or send it back to the 
+author(s) for revision.  
+
+If Guido van Rossum accepts the PEP, then its status is changed to
+'Accepted'.  If the reference implementation is not already complete,
+it must then be completed. When the reference implementation is
+complete and accepted (again by Guido van Rossum), the status will be
+changed to 'Final'.  In our case, we wouldn't even write the PEP
+without having a complete reference implementation, since what we
+would be proposing is to make PyPy and not CPython the complete
+reference implementation of the language.  Thus the expression of
+interest from Guido van Rossum is of extreme significance.  It is
+likely, though not certain, that PyPy will become the standard
+reference implementation of the Python language.
+
+The complete details of how to write a PEP are themselves an
+Informational PEP -- PEP #1 in fact.  Complete details are to
+be found in this appendex:
+
+FIXME include http://www.python.org/peps/pep-0001.html