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

[M.-A. Lemburg]

Brett Cannon wrote:
> On Mon, Aug 26, 2013 at 2:54 PM, 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.
> 
> 
> Not quite. Antoine's point is that the flags used to start Python are
> needed to set up certain things that may influence how using e.g. argparse
> works. Importlib is in a unique position because I wrote it from the
> beginning to be bootstrapped, so I designed it to deal with bootstrapping
> issues. It also led to the code being a little odd and having to work
> around things like lacking imports, etc. Argparse (and any of its
> dependencies) have not been designed in such a fashion, especially if they
> are directly involved in setting key settings in the interpreter.

There are some parts which cannot easily be done in Python
at startup time, but a lot of the logic used for running
the prompt or loading and running Python scripts can easily be
done in Python.

See the pyrun code for an example of what can easily be
implemented in Python:

http://www.egenix.com/products/python/PyRun/

pyrun emulates many Python interpreter startup features
in pure Python.

While working on that emulation, I found quite a few quirky "features"
in the interpreter that could use some cleanup or at least proper
documentation, e.g. the way sys.path is setup for the various
different ways of running Python code from the command prompt.

In one of the next pyrun releases, I want to refactor the code
into a separate module to make the various bits more accessible
and usable outside pyrun.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/