On Mon, Aug 31, 2009 at 06:36, Nick Coghlan
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