<br><br><div class="gmail_quote">On Sun, Apr 6, 2008 at 3:09 AM, Brett Cannon <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Sat, Apr 5, 2008 at 11:11 PM, Benjamin Peterson<br>
<div><div></div><div class="Wj3C7c"><<a href="mailto:musiccomposition@gmail.com">musiccomposition@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
><br>
> On Sat, Apr 5, 2008 at 4:04 PM, Brett Cannon <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br>
> > On Sat, Apr 5, 2008 at 6:13 PM, Benjamin Peterson<br>
> ><br>
> ><br>
> ><br>
> > <<a href="mailto:musiccomposition@gmail.com">musiccomposition@gmail.com</a>> wrote:<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > On Sat, Apr 5, 2008 at 10:37 AM, Brett Cannon <<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br>
> > > ><br>
> > > > On Sat, Apr 5, 2008 at 4:58 PM, Benjamin Peterson<br>
> > > > <<a href="mailto:musiccomposition@gmail.com">musiccomposition@gmail.com</a>> wrote:<br>
> > > > > Here's an updated version:<br>
> > > > ><br>
> > > > ><br>
> > > > > - display_hook, stdout, stdin, and stderr<br>
> > > > > - flags and warn_options<br>
> > > > > - settrace, and setprofile<br>
> > > > > - traceback, excepthook<br>
> > > > > - etc...<br>
> > > > ><br>
> > > ><br>
> > > > You still need to get rid of the "etc.". Beyond being explicit, it<br>
> > > > makes it easier for people reviewing the PEP to see what they think<br>
> > > > might be better placed in the new module.<br>
> > ><br>
> > > PEP: XXX<br>
> > > Title: 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<br>
> interpreter<br>
> > > functions in order to clean out the sys module and separate general<br>
> 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<br>
> into<br>
> > > two<br>
> > > major groups:<br>
> > ><br>
> > > 1. Data and functions that are available in all Python implementations<br>
> and<br>
> > > deal<br>
> > > with the general running of a Python VM.<br>
> > ><br>
> > > - argv<br>
> > > - byteorder<br>
> > > - builtin_module_names, path, and modules<br>
> ><br>
> > builtin_module_names is an implementation detail and thus should be moved.<br>
> ><br>
> ><br>
> > > - subversion, copyright, hexversion, version, and version_info<br>
> ><br>
> > Ditto for subversion.<br>
> ><br>
> ><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>
> ><br>
> > dont_write_bytecode might be better off in the new module, but then<br>
> > bytecode is part of the stdlib. I guess it depends on how the other<br>
> > interpreters view bytecode. They could easily just have it always set<br>
> > to False.<br>
> What do you think about moving it to imp.<br>
><br>
<br>
</div></div>Fine by me, but some people still seem to think this is an<br>
implementation detail. Since there is a lack of a clear solution for<br>
this I say make it an Open Issue and wait until python-dev is brought<br>
into this to figure it out.</blockquote><div>Ok. Here's another version:<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> - builtin_module_names, path, 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<br> - getwindowsversion<br> - maxint and maxunicode<br> - platform<br> - ps1 and ps2<br> - stdin, stderr, stdout, __stdin__, __stderr__, __stdout__<br>
- tracebacklimit<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><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><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>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></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<font color="#888888"><br>
-Brett<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Cheers,<br>Benjamin Peterson