<div dir="ltr">What about something like the following to simulate a "restart", portably.<br><div><br>def restart():<br>    import sys<br>    import os<br>    import subprocess<br>    if os.getenv("PYTHON_EXIT_ON_RESTART") == "1":<br>        sys.exit(42)<br>    else:<br>        env = os.environ.copy()<br>        env["PYTHON_EXIT_ON_RESTART"] = "1"<br>        while True:<br>            sp = subprocess.run([sys.executable], env=env)<br>            if sp.returncode != 42:<br>                sys.exit(sp.returncode)<br>            <br></div>Stephan</div><div class="gmail_extra"><br><div class="gmail_quote">2017-10-30 17:33 GMT+01:00 Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 30 October 2017 at 16:22, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
>> Also, on Windows, I believe that any emulation of execve either leaves<br>
>> the original process in memory, or has problems getting console<br>
>> inheritance right. It's been a long time since I worked at that level,<br>
>> and things may be better now, but getting a robust "restart this<br>
>> process" interface in Windows would need some care (that's one of the<br>
>> reasons the py launcher runs Python as a subprocess rather than doing<br>
>> any sort of exec equivalent).<br>
><br>
> As long as the standard streams are passed along correctly, whatever the py<br>
> launcher does would presumably be adequate for a REPL restart as well,<br>
> assuming we decided to go down that path.<br>
<br>
</span>The py launcher starts a subprocess for python.exe and waits on it. I<br>
wouldn't have thought that's going to work for installing mods in a<br>
REPL - imagine a long working session where I install 10 mods as I<br>
explore options for a particular problem (I don't know how likely that<br>
is in practice...) - there'd be a chain of 10+ Python processes, only<br>
the last of which is still useful. It's probably not a massive problem<br>
(I assume everything but the last process is paged out) but it's not<br>
exactly friendly.<br>
<br>
OTOH, if you lose the command history and the interpreter state after<br>
each install, you'll probably get fed up long before the number of<br>
processes is an issue...<br>
<span class=""><br>
> It would also be reasonable to say that the regular REPL just issues a<br>
> warning that a restart might be needed, and it's only REPLs with a separate<br>
> client process that offer a way to restart the subprocess where code<br>
> actually executes.<br>
<br>
</span>This feels awfully like the traditional Windows "your mouse has moved<br>
- please reboot to have your changes take effect" behaviour. I don't<br>
think we're going to impress many people emulating that :-(<br>
<div class="HOEnZb"><div class="h5"><br>
Paul<br>
______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br>
</div></div></blockquote></div><br></div>