On Fri, Apr 4, 2008 at 10:27 AM, Benjamin Peterson < musiccomposition@gmail.com> wrote:
On Fri, Apr 4, 2008 at 10:01 AM, Steven Bethard
wrote: On Fri, Apr 4, 2008 at 11:27 AM, Christian Heimes
wrote: Once the pyvm module is implemented the sys module should only contain system methods which can be implemented by all flavors of Python.
On Fri, Apr 4, 2008 at 5:44 AM, Brett Cannon
wrote: This is exactly the type of separation I want to see. [snip] Sound good to people? If so, who wants to take this on?
2008/4/4 Benjamin Peterson
: If there is further support, I will.
I don't know how much more further support you need, but I'm 100% behind the idea. If you need any more help, let me know.
I'm starting the PEP now...
And here it is: This is my first PEP, so do be brutal with your feedback. PEP: XXX Title: The interpreter module Version: $Revision$ Last-Modified: $Date$ Author: Benjamin Peterson Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 4-April-2008 Python-Version: 3.0 Abstract ======== This PEP proposes a new low-level module for CPython-specific interpreter functions in order to clean out the sys module and separate general Python functionality from implementation details. Rationale ========= The sys module currently contains functions and data that can be put into two major groups: 1. Data and functions that are available in all Python implementations and deal with the general running of a Python VM. - display_hook, stdout, stdin, and stderr - flags and warn_options - settrace, and setprofile - traceback, excepthook - etc... 2. Data and function that affect the CPython interpreter. - get/setrecursionlimit - get/setcheckinterval - _getframe and _current_frame - getrefcount - getdlopenflags The second collections of items has been steadily increasing over the years causing clutter in sys. Guido has even said he doesn't recognize some of things in it [#bug-1522]_! Other implementations have clearly struggled with what to do about the contents of sys they can't implement but must to retain compatibility. For example, Jython's sys module has dud set/getrecursionlimit functions. Moving these items items off to another module would send a clear message about what functions need and need not be implemented. It has also been proposed that the contents of types module be distributed across the standard library [#types-removal]_; the interpreter module would provide an excellent resting place for internal types like frames and code objects. Specification ============= A new builtin module named "interpreter" (see `Naming`_) will be added. The functions mentioned in the above list will be moved to it. Transition Plan =============== Once implemented in 3.x, the interpreter module will be back-ported to 2.6. Py3k warnings will be added the the sys functions it replaces. Open Issues =========== Naming ------ The author proposes the name "interpreter" for the new module. "pyvm" has also been suggested [#pyvm-name]_. References ========== .. [#bug-1522] http://bugs.python.org/issue1522 .. [#types-removal] http://mail.python.org/pipermail/stdlib-sig/2008-April/000172.html .. [#pyvm-name] http://mail.python.org/pipermail/python-3000/2007-November/011351.html Copyright ========= This document has been placed in the public domain. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End:
Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy
-- Cheers, Benjamin Peterson
-- Cheers, Benjamin Peterson