[Python-Dev] runpy.py

[Brett Cannon]

On Mon, Aug 31, 2009 at 06:36, Nick Coghlan<ncoghlan at gmail.com> wrote:
> Chris Withers wrote:
>> Nick Coghlan wrote:
>>> The PEPs don't go into the process of how we actually hook the command
>>> line up to the runpy module though - that's something you need to dig
>>> into the main.c code to really understand.
>>
>> Yeah, main.c does quite a lot... ;-)
>>
>> This all spawned from a suggestion by Jim Fulton over on the
>> distutils-sig that it would be nice if there was a python module that
>> did all of the various types of launching found in main.c. His use case
>> is so that buildout scripts can easily use the same functionality that
>> the interpreter startup uses.
>>
>> I didn't spot any, but does anyone know of code in that mix that
>> couldn't be moved to a pure python module like runpy?
>>
>> If not, how would people feel about the various types of launching all
>> moving to runpy rather than just the -m stuff being there?
>
> I haven't timed it, but I believe runpy is a fair bit slower than the
> native C functions in main. (That first part of the comment means I
> could easily be wrong though - it's definitely possible that overall
> interpreter startup time will dwarf any difference between the two
> launch mechanisms).
>

That's quite possible. If you benchmark it you might be able to convince people.

> That said, while actually ditching the C code might cause an argument,
> expanding runpy with Python equivalents of the C level functionality
> (i.e. run script by name, run directory/zipfile by name, '-c' switch,
> and other odds and ends that I'm probably forgetting right now, with all
> associated modifications to sys.argv and the __main__ module attributes)
> should be far less controversial.
>

It also has the perk of letting alternative VMs not have to implement
all of that stuff themselves, potentially helping to unify even the
command-line interfaces for all the VMs.

-Brett