Chris Jerdonek added the comment: > 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14803> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
