<br><br><div class="gmail_quote">On Mon, Apr 16, 2012 at 13:04, "Martin v. Löwis" <span dir="ltr"><<a href="mailto:martin@v.loewis.de" target="_blank">martin@v.loewis.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>> I don't see how depending on Cython is better than depending on having<br>
> an existing Python. If the only benefit is semi-readable code, surely<br>
> we do have source code for the pre-frozen module, and it is just a matter<br>
> of convincing hg that the bytecode is binary, not text?<br>
<br>
</div>Cython-generated C code would likely be more stable (and produce<br>
compiler errors if it gets stale), whereas importlib.h needs to be<br>
regenerated with byte code changes.<br>
<br>
Having source code has the advantage that it becomes possible to<br>
single-step through the import process in C debugger. Single-stepping<br>
with pdb would, of course, be better than that, but I doubt it's<br>
feasible.<br>
<br>
In addition, there might be a performance gain with Cython over ceval.<br></blockquote><div><br></div><div>The other benefit is maintainability. In order to hit my roughly 5% startup speed I had to rewrite chunks of __import__() in C code and then delegate to importlib's Python code in cases where sys.modules was not hit. Using Cython would mean that can all go away and the differences between the C and Python code would become (supposedly) non-existent, making tweaks easier (e.g. when I made the change to hit sys.modules less when a loader returned the desired module it was annoying to have to change importlib *and* import.c).</div>
</div>