[Python-Dev] Created branch for PEP 302 phase 2 work (in C)
Phillip J. Eby
pje at telecommunity.com
Tue Oct 3 01:52:09 CEST 2006
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>
>>On 10/2/06, Phillip J. Eby
>><<mailto:pje at telecommunity.com>pje at telecommunity.com> wrote:
>> > 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.
More information about the Python-Dev