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 | ncogh...@gmail.com | Brisbane, Australia --------------------------------------------------------------- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
