[Python-Dev] runpy.py (original) (raw)

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.

Cheers, Nick.

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

More information about the Python-Dev mailing list