[Python-Dev] runpy.py

Nick Coghlan ncoghlan at gmail.com
Mon Aug 31 15:36:42 CEST 2009

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

For example, _run_module_as_main() has survived long enough now without
anyone poking holes in it (unlike the holes in the original run_module()
that PJE drove a truck through!) that I could probably be talked into
removing the comment I put on it and making it public :)

As you say, making all of that functionality accessible from Python
would allow launch scripts to be far more flexible in handling arguments
as if they were the normal interpreter.


Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia

More information about the Python-Dev mailing list