diff --git a/pep-3147.txt b/pep-3147.txt
index aaa66691d..fa3d28645 100644
--- a/pep-3147.txt
+++ b/pep-3147.txt
@@ -499,6 +499,8 @@ 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?
+Evidence shows that the extra stats can be fairly costly to start up
+time.
 
 There are several ways out of this.  Should we decide that it's
 important enough to support bytecode-only packages, the semantics
@@ -521,13 +523,17 @@ 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.
+  their code in a zip file, which is supported today.  Sub-options
+  include supporting pyc-only imports only in zip files, or still
+  requiring the py file for zip imports.
 * 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.
 * Add a marker to a package's `__init__.py` file to enable
   bytecode-only imports for everything else in the package.
+* Leave it to third-party tools such as py2exe [20]_ to build an
+  ecosystem and standards around source-less distributions.
 
 
 __cached__ vs. __compiled__
@@ -586,6 +592,9 @@ References
 
 .. [18] importlib: http://docs.python.org/3.1/library/importlib.html
 
+.. [19] http://mail.python.org/pipermail/python-dev/2010-March/098042.html
+
+.. [20] py2exe: http://www.py2exe.org/
 
 ACKNOWLEDGMENTS
 ===============