This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients belopolsky, eli.bendersky, georg.brandl, ncoghlan, terry.reedy
Date 2010-10-05.20:45:27
SpamBayes Score 3.5441976e-09
Marked as misclassified No
Message-id <>
In-reply-to <>
On Wed, Oct 6, 2010 at 2:59 AM, Alexander Belopolsky
<> wrote:
> Alexander Belopolsky <> added the comment:
> I am afraid, for ordinary scripts these modules effectively use option 3.  I think these modules should remove its own scaffolding from "real" __main__ before loading any traced code.  I am not sure how this can be achieved, though.

If you use runpy.run_module or runpy.run_path, they will switch the
existing __main__ out of sys.modules, replacing it with a temporary
module. However, that approach is currently slightly broken, in that
it leaves the temporary module namespace inaccessible if the module
execution fails with an exception (hence the existence of
run_module_as_main). I've thought of a few ways to fix that, but never
explored any of them:
- allow the module to be used for execution to be passed in to
run_module and run_path as a new optional parameter
- allow a list (or other mutable container) to be passed in as an
output parameter, and stick the temporary module in there
- define a thread-local variable for the runpy module that stores the
last module namespace executed via runpy in the current thread (and a
convenience API for retrieving it)

Option 2 strikes me as rather clumsy, so we can probably skip that. I
find option 3 to be quite elegant in a sys.exc_info() kind of way, but
option 1 is probably simpler.
Date User Action Args
2010-10-05 20:45:30ncoghlansetrecipients: + ncoghlan, georg.brandl, terry.reedy, belopolsky, eli.bendersky
2010-10-05 20:45:28ncoghlanlinkissue9325 messages
2010-10-05 20:45:27ncoghlancreate