Mailing List Archive: Python: Dev

Modules that run other scripts

Index | Next | Previous | View Threaded

ncoghlan at gmail

Nov 14, 2009, 10:04 PM

Post #1 of 3 (329 views)
Permalink

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 [at] gmail | Brisbane, Australia
---------------------------------------------------------------
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

robert.kern at gmail

Nov 14, 2009, 10:37 PM

Post #2 of 3 (296 views)
Permalink

Re: Modules that run other scripts [In reply to]

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

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

ncoghlan at gmail

Nov 14, 2009, 11:02 PM

Post #3 of 3 (297 views)
Permalink

Re: Modules that run other scripts [In reply to]

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 [at] gmail | Brisbane, Australia
---------------------------------------------------------------
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com