Message179882
| Author |
danielsh |
| Recipients |
Arfrever, Ben.Darnell, brett.cannon, danielsh, eric.araujo, flox, georg.brandl, ncoghlan, pitrou, rhettinger |
| Date |
2013年01月13日.15:42:34 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<20130113154210.GA2946@lp-shahaf.local> |
| In-reply-to |
<1358072218.3343.2.camel@localhost.localdomain> |
| Content |
Antoine Pitrou wrote on Sun, Jan 13, 2013 at 10:19:20 +0000:
>
> Antoine Pitrou added the comment:
>
> > I'm not seeing a good justification for doing anything more, though:
> >
> > - needing to access this information is an exceedingly niche use case
> > - I don't see any way for raw_argv to be useful in a cross-implementation manner.
>
> I expect it to be useful in the "launch (almost) the same command in the
> same way" situation.
> Not that it happens often :-)
What about the "launch a different command with the same interpreter
flags" use-case? For example, having 'python -E foo.py --foooptions'
want to execute 'python -E bar.py'.
Perhaps it'll be cleaner to expose in state_argv ['python', '-E']; in
sys.argv ['foo.py', '--foooptions']; and have scripts that want to exec
themselves use an idiomatic os.execv(sys.executable, sys.state_argv + sys.argv). |
|