<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 26, 2013 at 2:54 PM, Ned Batchelder <span dir="ltr"><<a href="mailto:ned@nedbatchelder.com" target="_blank">ned@nedbatchelder.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On 8/26/13 1:55 PM, Antoine Pitrou wrote:<br>


<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On Mon, 26 Aug 2013 16:36:53 +0200<br>
Draic Kin <<a href="mailto:drekin@gmail.com" target="_blank">drekin@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hello, it would be nice if reference pure Python implementation existed for<br>
more parts of interpreter core and the core actually used them. This was<br>
done for import machinery in Python 3.3 making importlib library.<br>
<br>
One potential target for this would be moving the logic of what python.exe<br>
does – parsing its arguments, finding the script to run, compiling its code<br>
and running as __main__ module, running REPL if it's in interactive mode<br>
afterwards. There could be a stdlib module exposing this logic, using<br>
argparse to parse the arguments, overhauled version of runpy to run the<br>
__main__ module and overhauled version of code to run the REPL. Python.exe<br>
would be just thin wrapper which bootstraps the interpreter and runs this<br>
runner module.<br>
</blockquote>
The interpreter needs a lot of information to be bootstrapped; you are<br>
proposing that the code which extracts that information be run *after*<br>
the interpreter is bootstrapped, which creates a nasty temporal problem.<br>
<br>
In the end, it may make maintenance *more* difficult, rather than less,<br>
to rewrite that code in Python.<br>
</blockquote></div>
It seems to me that this argument could have been made against the import rewrite in Python.</blockquote><div><br></div><div>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.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">  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?<br>

</blockquote><div><br></div><div>The exact location where importlib is bootstrapped is at <a href="http://hg.python.org/cpython/file/8fb3a6f9b0a4/Python/pythonrun.c#l387">http://hg.python.org/cpython/file/8fb3a6f9b0a4/Python/pythonrun.c#l387</a> . I think it happens as soon as humanly possible, but it also is in a very restricted environment that is atypical (e.g. no imports, only uses built-in modules, can't have any alternative encoding, etc.).</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I know it would be great to have the startup logic more accessible.</blockquote><div><br></div><div>Sure, but there is also a performance consideration to take in.</div><div><br></div><div>I wrote a blog post once on this topic: <a href="http://sayspy.blogspot.ca/2012/12/how-much-of-python-can-be-written-in.html">http://sayspy.blogspot.ca/2012/12/how-much-of-python-can-be-written-in.html</a> . Basically you might be able to pull off exceptions in Python because they are typically such simple chunks of code, but otherwise everything else is too performance-sensitive. To really dive in you would need to look at the C code and see what happens at what point to know if unmodified Python code could be used instead of the C code (or be willing to write it all from scratch to allow bootstrapping).</div>

</div></div></div>