Add a section discussion the options for bytecode-only packagers.

pep-3147.txt

@@ -355,12 +355,15 @@ didn't exist.  This location of course includes the `__pycache__`
 subdirectory in its path.
 
 For alternative Python implementations which do not support `pyc`
-files, the `__cached__` attribute may point to whatever
+files, the `__cached__` attribute may point to whatever information
-version-specific binary file was read for the module code.  E.g. on
+makes sense.  E.g. on Jython, this might be the `.class` file for the
-Jython, this might be the `.class` file for the module:
+module: `__pycache__/foo.jython-32.class`.  Some implementations may
-`__pycache__/foo.jython-32.class`.  Alternative implementations for
+use multiple files compiled files to create the module, in which case
-which this scheme does not make sense should set the `__cached__`
+`__cached__` may be a tuple.  The exact contents of `__cached__` are
-attribute to `None`.
+Python implementation specific.
+
+Alternative implementations for which this scheme does not make sense
+should set the `__cached__` attribute to `None`.
 
 
 File extension checks
@@ -475,6 +478,55 @@ guarantee that the pure-Python implementation and the built-in
 implementation remain in sync.
 
 
+Open issues
+===========
+
+bytecode-only packages
+----------------------
+
+Some users of Python distribute packages containing only the byte code
+files (pyc).  The use cases for this are to make it more difficult for
+end-users to view the source code, and to reduce maintenance burdens
+when end users casually edit the source files.
+
+This PEP currently promote no default support for bytecode-only
+packages.  The primary motivator for this are that we can reduce stat
+calls if the importer only looks for .py files, making Python start-up
+and import faster.
+
+The question is how to balance the requirements of bytecode-only users
+with the more universally beneficial faster start up times for
+requiring source files?  Should all Python users pay the extra stat
+call penalty in the general case for a minority use case by default?
+
+There are several ways out of this.  Should we decide that it's
+important enough to support bytecode-only packages, the semantics
+would be as follows:
+
+* If there is a traditional, non-magic-tagged .pyc file in the
+  location where a .py file should be found, it will satisfy the
+  import.
+* The `__file__` attribute of the module will point to the .pyc file.
+* The `__cached__` attribute of the module will point to the .pyc file
+  too.
+* The existence of a matching `__pycached__/foo.<magic>.pyc` file
+  without the source py file will *not* satisfy the import.   This
+  means that if the source file is removed, the pyc file will be
+  ignored (unlike in today's implementation).
+
+Other ways to satisfy the bytecode-only packagers requirements would
+have less impact on the general Python user population, and include:
+
+* Add a `-X` switch and/or environment variable to enable
+  the bytecode-only search algorithm.
+* Let those who want more protection against casual py hackers package
+  their code in a zip file, which is supported today.
+* Provide a custom importer supporting bytecode-only packages, which
+  would have to be enabled explicitly by the application.  Either
+  Python would provide such a custom importer or it would be left to
+  third parties to implement.
+
+
 References
 ==========