[Python-ideas] Move more parts of interpreter core to stdlib

[Draic Kin]

On Mon, Aug 26, 2013 at 9:30 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:

> On Mon, 26 Aug 2013 14:54:43 -0400
> Ned Batchelder <ned at nedbatchelder.com>
> wrote:
> > On 8/26/13 1:55 PM, Antoine Pitrou wrote:
> > > On Mon, 26 Aug 2013 16:36:53 +0200
> > > Draic Kin <drekin at gmail.com> wrote:
> > >> Hello, it would be nice if reference pure Python implementation
> existed for
> > >> more parts of interpreter core and the core actually used them. This
> was
> > >> done for import machinery in Python 3.3 making importlib library.
> > >>
> > >> One potential target for this would be moving the logic of what
> python.exe
> > >> does – parsing its arguments, finding the script to run, compiling
> its code
> > >> and running as __main__ module, running REPL if it's in interactive
> mode
> > >> afterwards. There could be a stdlib module exposing this logic, using
> > >> argparse to parse the arguments, overhauled version of runpy to run
> the
> > >> __main__ module and overhauled version of code to run the REPL.
> Python.exe
> > >> would be just thin wrapper which bootstraps the interpreter and runs
> this
> > >> runner module.
> > > The interpreter needs a lot of information to be bootstrapped; you are
> > > proposing that the code which extracts that information be run *after*
> > > the interpreter is bootstrapped, which creates a nasty temporal
> problem.
> > >
> > > In the end, it may make maintenance *more* difficult, rather than less,
> > > to rewrite that code in Python.
> > It seems to me that this argument could have been made against the
> > import rewrite in Python.  I don't know enough about the various factors
> > to know what the differences are between the two scenarios (import and
> > startup) to know whether it's a valid argument here or not. Can someone
> > elaborate?
>
> The import system is algorithmically non-trivial, and it needs to be
> easily reusable by outside code. These are two good reasons to write the
> implementation in Python. The early startup sequence, on the other
> hand, is trivially sequential and can't be reused by user code (by
> construction: once the interpreter is initialized, you can't run the
> startup sequence again).
>
> The one thing that may be considered is whether there is a point in
> having two versions of the interactive prompt: the default one in C,
> and a re-usable Python one in code.py.
>
> There are also subtle differences between the two. E.g. whether to write
the prompt to stdout or stderr, how to behave when attributes sys.ps1,
sys.ps2 are missing, and of course whether to get input from sys.stdin or
the standard STDIN.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20130826/bd5a3b02/attachment.html>