Nick Coghlan added the comment:
Thanks for the ping.
The actual code changes look OK to me for the initially proposed design, which
means the main missing piece would be documentation updates (both to the
docstrings and to runpy module reference).
However, thinking about how those docs might be written, I'm starting to think
the specific proposed design would be inherently confusing for folks that
aren't already familiar with runpy's internals, and it might be better to use a
callback API with a few predefined helper functions.
That is, suppose the new parameter was a callback accepting the following
parameters:
* "module" - the module about to be executed
* "argv" - sys.argv prior to module execution
And then we have 3 predefined callbacks/callback factories in runpy:
def keep_argv(module, argv):
return argv
def set_argv0(module, argv):
return module.__file__ + argv[1:]
def set_argv(argv, *, implicit_argv0=True):
argv_override = list(argv)
if implicit_argv0:
def _set_argv(module, original_argv):
return [module.__file__] + argv_override
else:
def _set_argv(module, original_argv):
return argv_override
return _set_argv
Then the three scenarios in your original post would look like:
runpy.run_module(mod_name, argv=set_argv0)
runpy.run_module(mod_name, argv=keep_argv)
runpy.run_module(mod_name, argv=set_argv(iterable))
(and similarly for run_path)
"argv=None" would be the default, and equivalent to specifying "argv=set_argv0"
"argv=set_argv(iterable, implicit_argv0=False)" would allow even more precise
control of the argv settings seen by the running module.
Future and/or custom variations would be straightforward, since we're just
passing in a callable.
The documentation benefit is that the "argv" parameter docs can just describe
the callback signature and the use of "set_argv0" as the default, with the
details of the individual behaviours moving to the definitions of the
corresponding functions.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26388>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
