[stdlib-sig] Proposal: new "interpreter" module
musiccomposition at gmail.com
Sat Apr 5 23:11:58 CEST 2008
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
> > functions in order to clean out the sys module and separate general
> > functionality from implementation details.
> > Rationale
> > =========
> > The sys module currently contains functions and data that can be put
> > two
> > major groups:
> > 1. Data and functions that are available in all Python implementations
> > 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.
> > - getfilesystemencoding
> > - get/setprofile
> > - get/settrace
> > - getwindowsversion
> > - maxint and maxunicode
> > - platform
> > - ps1 and ps2
> > - stdin, stderr, stdout, __stdin__, __stderr__, __stdout__
> > - tracebacklimit
> Perhaps we should have sys.interpreter or sys.vm? That way e.g. Jython
> no longer has to override sys.platform to specify that VM-specific
> changes are in effect?
That's a wonderful idea. Then you wouldn't have to resort to sys.platform
being "java" and such tricks.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the stdlib-sig