Modules that run other scripts
I'm in the process of adding a "run_path" function to the runpy module that allows Python code to execute scripts using the same rules as the CPython command line (i.e. accepting both source and compiled Python files in addition to zipfiles, directories and other valid sys.path entries containing a __main__.py file). After that I was considering looking at the standard library to see which modules can be used to execute other scripts (e.g. pdb, profile) and determine what would be involved in updating them to support the same flexibility as the main command line (possibly including adding their own "-m" option to run modules by name rather than file path location). For that second part: 1. Is it even worth doing at this stage? I'm not sure to what degree the new command line flexibility has even been adopted by third party application packagers, so I have no idea how large the pool of potential users might be. Should I instead wait until we start seeing complaints that these tools can't be used with script references that the main command line will handle quite happily? 2. Aside from runpy itself, pdb and profile are the only examples that spring to mind when I try to think of standard library modules that execute other Python scripts. Are there any others that I'm missing? (Even if we decide not to do anything at this stage, collating such a list may still be handy for future reference) Regards, Nick. P.S. pdb in particular may be messy to update, since the interaction between the way it provides exception post-mortem debugging support and the way the runpy module tries to avoid mutating the application's own __main__ module will likely require careful handling. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
Nick Coghlan wrote:
For that second part: 1. Is it even worth doing at this stage? I'm not sure to what degree the new command line flexibility has even been adopted by third party application packagers, so I have no idea how large the pool of potential users might be. Should I instead wait until we start seeing complaints that these tools can't be used with script references that the main command line will handle quite happily?
There is a small, but important class of "scripts that run scripts", which are mostly all development tools (e.g. coverage, my line_profiler, etc.). Doing this correctly in all of the corner cases is reasonably tricky, so I think this is a perfect case for having the functionality implemented once in the standard library. For what its worth, I think Ned Batchelder did the most thorough job of implementing this in the latest version of coverage: http://bitbucket.org/ned/coveragepy/src/tip/coverage/execfile.py -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
Robert Kern wrote:
Nick Coghlan wrote:
For that second part: 1. Is it even worth doing at this stage? I'm not sure to what degree the new command line flexibility has even been adopted by third party application packagers, so I have no idea how large the pool of potential users might be. Should I instead wait until we start seeing complaints that these tools can't be used with script references that the main command line will handle quite happily?
There is a small, but important class of "scripts that run scripts", which are mostly all development tools (e.g. coverage, my line_profiler, etc.). Doing this correctly in all of the corner cases is reasonably tricky, so I think this is a perfect case for having the functionality implemented once in the standard library.
Yep, that part I'm convinced of the need for - hence runpy.run_path. It's whether the immediate demand is there to justify tinkering with the existing tools in the standard library that I'm not sure about (particularly when there is a risk of altering behaviour in some corner cases).
For what its worth, I think Ned Batchelder did the most thorough job of implementing this in the latest version of coverage:
http://bitbucket.org/ned/coveragepy/src/tip/coverage/execfile.py
That's actually fairly similar to what run_path will do in the simple script case (zipfile and directory execution is a fair bit messier in practice, but based on a similar concept in principle). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
participants (2)
-
Nick Coghlan
-
Robert Kern