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

[Brett Cannon]

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.

-Brett