<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>