[stdlib-sig] Proposal: new "interpreter" module

Benjamin Peterson musiccomposition at gmail.com
Sun Apr 6 14:45:36 CEST 2008 

On Sun, Apr 6, 2008 at 3:09 AM, Brett Cannon <brett at python.org> wrote:

> On Sat, Apr 5, 2008 at 11:11 PM, Benjamin Peterson
> <musiccomposition at gmail.com> wrote:
> >
> >
> >
> >
> > On Sat, Apr 5, 2008 at 4:04 PM, Brett Cannon <brett at python.org> wrote:
> > > On Sat, Apr 5, 2008 at 6:13 PM, Benjamin Peterson
> > >
> > >
> > >
> > > <musiccomposition at gmail.com> wrote:
> > > >
> > > >
> > > >
> > > >
> > > > On Sat, Apr 5, 2008 at 10:37 AM, Brett Cannon <brett at python.org>
> wrote:
> > > > >
> > > > > On Sat, Apr 5, 2008 at 4:58 PM, Benjamin Peterson
> > > > > <musiccomposition at gmail.com> wrote:
> > > > > > Here's an updated version:
> > > > > >
> > > > > >
> > > > > >    - display_hook, stdout, stdin, and stderr
> > > > > >    - flags and warn_options
> > > > > >    - settrace, and setprofile
> > > > > >    - traceback, excepthook
> > > > > >    - etc...
> > > > > >
> > > > >
> > > > > You still need to get rid of the "etc.". Beyond being explicit, it
> > > > > makes it easier for people reviewing the PEP to see what they
> think
> > > > > might be better placed in the new module.
> > > >
> > > > 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.
> > > >
> > > >    - argv
> > > >    - byteorder
> > > >    - builtin_module_names, path, and modules
> > >
> > > builtin_module_names is an implementation detail and thus should be
> moved.
> > >
> > >
> > > >    - subversion, copyright, hexversion, version, and version_info
> > >
> > > Ditto for subversion.
> > >
> > >
> > > >    - displayhook, __displayhook__
> > > >     - excepthook, __excepthook__, exc_info, and exc_clear
> > > >    - exec_prefix and prefix
> > > >    - executable
> > > >    - exit
> > > >    - flags, py3kwarning, dont_write_bytecode, and warn_options
> > >
> > > dont_write_bytecode might be better off in the new module, but then
> > > bytecode is part of the stdlib. I guess it depends on how the other
> > > interpreters view bytecode. They could easily just have it always set
> > > to False.
> > What do you think about moving it to imp.
> >
>
> Fine by me, but some people still seem to think this is an
> implementation detail. Since there is a lack of a clear solution for
> this I say make it an Open Issue and wait until python-dev is brought
> into this to figure it out.

Ok. Here's another version:

PEP: XXX
Title: Cleaning out sys and 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.

   - argv
   - byteorder
   - builtin_module_names, path, and modules
   - copyright, hexversion, version, and version_info
   - displayhook, __displayhook__
   - excepthook, __excepthook__, exc_info, and exc_clear
   - exec_prefix and prefix
   - executable
   - exit
   - flags, py3kwarning, dont_write_bytecode, and warn_options
   - getfilesystemencoding
   - get/setprofile
   - get/settrace
   - getwindowsversion
   - maxint and maxunicode
   - platform
   - ps1 and ps2
   - stdin, stderr, stdout, __stdin__, __stderr__, __stdout__
   - tracebacklimit


2. Data and functions that affect the CPython interpreter.

   - get/setrecursionlimit
   - get/setcheckinterval
   - _getframe and _current_frame
   - getrefcount
   - get/setdlopenflags
   - settscdumps
   - api_version
   - winver
   - dllhandle
   - float_info
   - _compact_freelists
   - _clear_type_cache
   - subversion

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 second list of items above will be split into the stdlib as follows:

The interpreter module
    - get/setrecursionlimit
    - get/setcheckinterval
    - _getframe and _current_frame
    - get/setdlopenflags
    - settscdumps
    - api_version
    - winver
    - dllhandle
    - float_info
    - _clear_type_cache
    - subversion

The gc module:
    - getrefcount
    - _compact_freelists


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
===========

What should move?
-----------------

dont_write_bytecode
^^^^^^^^^^^^^^^^^^^^

Some believe that the writing of bytecode is an implementation detail and
should
be moved [#bytecode-issue]_.  The counterargument is that all current,
complete
Python implementations do write some sort of bytecode, so it is valuable to
be
able to disable it.  Also, if it is moved, some wish to put it in the imp
module.


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

.. [#bytecode-issue]

   http://mail.python.org/pipermail/stdlib-sig/2008-April/000217.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:


>
>
> -Brett
>



-- 
Cheers,
Benjamin Peterson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/stdlib-sig/attachments/20080406/0086244f/attachment.htm

More information about the stdlib-sig mailing list