Message167005
> However, the -C option doesn't cover the case of *implicit* invocation of subprocesses. This is where the PYTHONRUNFIRST suggestion comes in
Would a more general solution than PYTHONRUNFIRST be something like a suitably named PYTHONRUNINSTEAD? This would be an arbitrary script to run in place of python any time python was invoked. Alternatively (and less powerfully), it could be a default set of command options to pass to the Python executable. Both of these seem more general than PYTHONRUNFIRST because the 'runas' command could itself be `python -C $PYTHONRUNFIRST ....`
> unless -E is specified, then -C $PYTHONRUNFIRST would be implied. To be honest, I *don't* think this latter capability should be built into the core implementation.... so that it doesn't inadvertently affect invocation of other applications (like hg)
It seems what you're saying is that you'd want PYTHONRUNFIRST to run only in special situations, rather than as the default. Is there a sense then in which a functionality inverse to -E could be provided? The idea would be that, when running Python, you could somehow instruct that an option like PYTHONRUN* would take effect only for the subprocesses spawned by the main process you're invoking (kind of like a context manager for the invocation of Python itself)?
The advantage of this approach would be that a special PYTHONRUNFIRST setting wouldn't take effect unless you explicitly say so. |
|
Date |
User |
Action |
Args |
2012-07-31 14:55:57 | chris.jerdonek | set | recipients:
+ chris.jerdonek, ncoghlan, pitrou, nedbat, serhiy.storchaka, bkabrda |
2012-07-31 14:55:57 | chris.jerdonek | set | messageid: <1343746557.77.0.765452759861.issue14803@psf.upfronthosting.co.za> |
2012-07-31 14:55:57 | chris.jerdonek | link | issue14803 messages |
2012-07-31 14:55:56 | chris.jerdonek | create | |
|