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 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).
History
Date User Action Args
2013-01-13 15:42:34danielshsetrecipients: + danielsh, brett.cannon, georg.brandl, rhettinger, ncoghlan, pitrou, eric.araujo, Arfrever, flox, Ben.Darnell
2013-01-13 15:42:34danielshlinkissue14208 messages
2013-01-13 15:42:34danielshcreate