[Python-checkins] peps: Update rejected/open ideas for PEP 488 along with minor grammatical fixes

[brett.cannon]

https://hg.python.org/peps/rev/b60b8e93b168
changeset:   5727:b60b8e93b168
user:        Brett Cannon <brett at python.org>
date:        Fri Mar 13 09:31:36 2015 -0400
summary:
  Update rejected/open ideas for PEP 488 along with minor grammatical fixes

files:
  pep-0488.txt |  67 +++++++++++++++++++++++++++++++--------
  1 files changed, 53 insertions(+), 14 deletions(-)


diff --git a/pep-0488.txt b/pep-0488.txt
--- a/pep-0488.txt
+++ b/pep-0488.txt
@@ -125,7 +125,7 @@
 ---------
 
 As ``importlib.util.cache_from_source()`` is the API that exposes
-bytecode file paths as while as being directly used by importlib, it
+bytecode file paths as well as being directly used by importlib, it
 requires the most critical change. As of Python 3.4, the function's
 signature is::
 
@@ -160,7 +160,7 @@
 ``None`` argument will mean the same as for ``optimization``). A
 deprecation warning will be raised when ``debug_override`` is given a
 value other than ``None``, but there are no plans for the complete
-removal of the parameter as this time (but removal will be no later
+removal of the parameter at this time (but removal will be no later
 than Python 4).
 
 The various module attributes for importlib.machinery which relate to
@@ -183,7 +183,7 @@
 ``compileall`` functions will be updated as necessary to make sure
 they follow the new bytecode file name semantics [6]_, [1]_. The CLI
 for the ``compileall`` module will not be directly affected (the
-``-b`` flag will be implicitly as it will no longer generate ``.pyo``
+``-b`` flag will be implicit as it will no longer generate ``.pyo``
 files when ``-O`` is specified).
 
 
@@ -215,14 +215,23 @@
 Rejected Ideas
 ==============
 
-N/A
+Completely dropping optimization levels from CPython
+----------------------------------------------------
 
+Some have suggested that instead of accommodating the various
+optimization levels in CPython, we should instead drop them
+entirely. The argument is that significant performance gains would
+occur from runtime optimizations through something like a JIT and not
+through pre-execution bytecode optimizations.
 
-Open Issues
-===========
+This idea is rejected for this PEP as that ignores the fact that
+there are people who do find the pre-existing optimization levels for
+CPython useful. It also assumes that no other Python interpreter
+would find what this PEP proposes useful.
 
-Formatting of the optimization level in the file name
------------------------------------------------------
+
+Alternative formatting of the optimization level in the file name
+-----------------------------------------------------------------
 
 Using the "opt-" prefix and placing the optimization level between
 the cache tag and file extension is not critical. All options which
@@ -240,9 +249,35 @@
 
 These were initially rejected either because they would change the
 sort order of bytecode files, possible ambiguity with the cache tag,
-or were not self-documenting enough.
+or were not self-documenting enough. An informal poll was taken and
+people clearly preferred the formatting proposed by the PEP [9]_.
+Since this topic is non-technical and of personal choice, the issue
+is considered solved.
 
 
+Embedding the optimization level in the bytecode metadata
+---------------------------------------------------------
+
+Some have suggested that rather than embedding the optimization level
+of bytecode in the file name that it be included in the file's
+metadata instead. This would mean every interpreter had a single copy
+of bytecode at any time. Changing the optimization level would thus
+require rewriting the bytecode, but there would also only be a single
+file to care about.
+
+This has been rejected due to the fact that Python is often installed
+as a root-level application and thus modifying the bytecode file for
+modules in the standard library are always possible. In this
+situation integrators would need to guess at what a reasonable
+optimization level was for users for any/all situations. By
+allowing multiple optimization levels to co-exist simultaneously it
+frees integrators from having to guess what users want and allows
+users to utilize the optimization level they want.
+
+
+Open Issues
+===========
+
 Not specifying the optimization level when it is at 0
 -----------------------------------------------------
 
@@ -260,11 +295,12 @@
 interpreter didn't support ``-O`` **and** didn't implement the ast
 module, else users could implement their own optimizations.
 
-Arguments against allow this special case is "explicit is better than
-implicit" and "special cases aren't special enough to break the
-rules". There are also currently no Python 3 interpreters that don't
-support ``-O``, so a potential Python 3 implementation which doesn't
-allow bytecode optimization is entirely theoretical at the moment.
+Arguments against allowing this special case is "explicit is better
+than implicit" and "special cases aren't special enough to break the
+rules".
+
+At this people have weakly supporting this idea while no one has
+explicitly come out against it.
 
 
 References
@@ -294,6 +330,9 @@
 .. [8] ``importlib.util.MAGIC_NUMBER``
    (https://docs.python.org/3/library/importlib.html#importlib.util.MAGIC_NUMBER)
 
+.. [9] Informal poll of file name format options on Google+
+   (https://plus.google.com/u/0/+BrettCannon/posts/fZynLNwHWGm)
+
 
 Copyright
 =========

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