<br>[snip]<br><br>With more comments taken into consideration:<br><br>PEP: XXX<br>Title: Cleaning out sys and the interpreter module<br>Version: $Revision$<br>Last-Modified: $Date$<br>Author: Benjamin Peterson<br>Status: Draft<br>
Type: Standards Track<br>Content-Type: text/x-rst<br>Created: 4-April-2008<br>Python-Version: 3.0<br><br><br>Abstract<br>========<br><br>This PEP proposes a new low-level module for CPython-specific interpreter<br>functions in order to clean out the sys module and separate general Python<br>
functionality from implementation details.<br><br><br>Rationale<br>=========<br><br>The sys module currently contains functions and data that can be put into two<br>major groups:<br><br>1. Data and functions that are available in all Python implementations and deal<br>
with the general running of a Python VM.<br><br> - argv<br> - byteorder<br> - path, path_hooks, meta_path, path_importer_cache, and modules<br> - copyright, hexversion, version, and version_info<br> - displayhook, __displayhook__<br>
- excepthook, __excepthook__, exc_info, and exc_clear<br> - exec_prefix and prefix<br> - executable<br> - exit<br> - flags, py3kwarning, dont_write_bytecode, and warn_options<br> - getfilesystemencoding<br> - get/setprofile<br>
- get/settrace, call_tracing<br> - getwindowsversion<br> - maxint and maxunicode<br> - platform<br> - ps1 and ps2<br> - stdin, stderr, stdout, __stdin__, __stderr__, __stdout__<br> - tracebacklimit<br> - intern<br>
<br><br>2. Data and functions that affect the CPython interpreter.<br> <br> - get/setrecursionlimit<br> - get/setcheckinterval<br> - _getframe and _current_frame<br> - getrefcount<br> - get/setdlopenflags<br>
- settscdumps<br> - api_version<br> - winver<br> - dllhandle<br> - float_info<br> - _compact_freelists<br> - _clear_type_cache<br> - subversion<br> - builtin_module_names<br> - callstats<br><br>The second collections of items has been steadily increasing over the years<br>
causing clutter in sys. Guido has even said he doesn't recognize some of things<br>in it [#bug-1522]_!<br><br>Other implementations have clearly struggled with what to do about the contents<br>of sys they can't implement but must to retain compatibility. For example,<br>
Jython's sys module has dud set/getrecursionlimit functions. Moving these items<br>items off to another module would send a clear message about what functions need<br>and need not be implemented.<br><br>It has also been proposed that the contents of types module be distributed<br>
across the standard library [#types-removal]_; the interpreter module would<br>provide an excellent resting place for internal types like frames and code<br>objects.<br><br>Specification<br>=============<br><br>A new builtin module named "interpreter" (see `Naming`_) will be added.<br>
<br>The second list of items above will be split into the stdlib as follows:<br><br>The interpreter module<br> - get/setrecursionlimit<br> - get/setcheckinterval<br> - _getframe and _current_frame<br> - get/setdlopenflags<br>
- settscdumps<br> - api_version<br> - winver<br> - dllhandle<br> - float_info<br> - _clear_type_cache<br> - subversion<br> - builtin_module_names<br> - callstats<br><br>The gc module:<br> - getrefcount<br>
- _compact_freelists<br><br><br>Transition Plan<br>===============<br><br>Once implemented in 3.x, the interpreter module will be back-ported to 2.6.<br>Py3k warnings will be added the the sys functions it replaces.<br>
<br><br>Open Issues<br>===========<br><br>What should move?<br>-----------------<br><br>dont_write_bytecode<br>^^^^^^^^^^^^^^^^^^^^<br><br>Some believe that the writing of bytecode is an implementation detail and should<br>
be moved [#bytecode-issue]_. The counterargument is that all current, complete<br>Python implementations do write some sort of bytecode, so it is valuable to be<br>able to disable it. Also, if it is moved, some wish to put it in the imp<br>
module.<br><br><br>Move to some to imp?<br>--------------------<br><br>It was noted that dont_write_bytecode or maybe builtin_module_names might fit<br>nicely in the imp module.<br><br><br>Naming<br>------<br><br>The author proposes the name "interpreter" for the new module. "pyvm" has also<br>
been suggested [#pyvm-name]_.<br><br><br>References<br>==========<br><br>.. [#bug-1522]<br><br> <a href="http://bugs.python.org/issue1522">http://bugs.python.org/issue1522</a><br><br>.. [#types-removal]<br><br> <a href="http://mail.python.org/pipermail/stdlib-sig/2008-April/000172.html">http://mail.python.org/pipermail/stdlib-sig/2008-April/000172.html</a><br>
<br>.. [#bytecode-issue]<br><br> <a href="http://mail.python.org/pipermail/stdlib-sig/2008-April/000217.html">http://mail.python.org/pipermail/stdlib-sig/2008-April/000217.html</a><br><br>.. [#pyvm-name]<br><br> <a href="http://mail.python.org/pipermail/python-3000/2007-November/011351.html">http://mail.python.org/pipermail/python-3000/2007-November/011351.html</a><br>
<br>Copyright<br>=========<br><br> This document has been placed in the public domain.<br><br><br> <br>Local Variables:<br>mode: indented-text<br>indent-tabs-mode: nil<br>sentence-end-double-space: t<br>fill-column: 70<br>
coding: utf-8<br>End:<br><br clear="all"><br>-- <br>Cheers,<br>Benjamin Peterson