[Python-Dev] Created branch for PEP 302 phase 2 work (in C)

[Phillip J. Eby]

At 03:48 PM 10/2/2006 -0700, Brett Cannon wrote:


>On 10/2/06, Paul Moore <<mailto:p.f.moore at gmail.com>p.f.moore at gmail.com> 
>wrote:
>>On 10/2/06, Phillip J. Eby 
>><<mailto:pje at telecommunity.com>pje at telecommunity.com> wrote:
>>[SNIP]
>> > I'm surprised, however, that you think working on this in C is going to be
>> > *less* time than it would take to simply replace __import__ with a Python
>> > function that reimplements PEP 302...
>>
>>That I do agree with. There's a bootstrapping issue (you can't import
>>the Python module that does all this without using a C-coded import
>>mechanism) but that should be resolvable.
>
>This is why I asked for input from people on which would take less 
>time.  Almost all the answers I got was that the the C code was delicate 
>but that it was workable.  Several people said they wished for a Python 
>implementation, but hardly anyone said flat-out, "don't waste your time, 
>the Python version will be faster to do".
>
>As for the bootstrapping, I am sure it is resolvable as well.  There are 
>several ways to go about it that are all tractable.

When I implemented the PEP 302 fix for the import speedups, I basically 
prototyped it using Python code that got loaded prior to 'site.py'.  Once I 
had the Python version solid, I converted it to a C type via 
straightforward code transcription.  That's pretty much the route I would 
follow for this too, although of course "freezing" the Python version into 
C code is also an option, since there's not much performance benefit to be 
had from a C translation, except for two parts of __import__: the part that 
checks sys.modules to shortcut the process, and the part that runs after 
the target module has been loaded or found.  Aside from this "fast path" 
part of __import__, any additional interpretation overhead will probably be 
dwarfed by I/O considerations.