On 30 October 2017 at 16:22, Nick Coghlan <ncogh...@gmail.com> wrote: >> Also, on Windows, I believe that any emulation of execve either leaves >> the original process in memory, or has problems getting console >> inheritance right. It's been a long time since I worked at that level, >> and things may be better now, but getting a robust "restart this >> process" interface in Windows would need some care (that's one of the >> reasons the py launcher runs Python as a subprocess rather than doing >> any sort of exec equivalent). > > As long as the standard streams are passed along correctly, whatever the py > launcher does would presumably be adequate for a REPL restart as well, > assuming we decided to go down that path.
The py launcher starts a subprocess for python.exe and waits on it. I wouldn't have thought that's going to work for installing mods in a REPL - imagine a long working session where I install 10 mods as I explore options for a particular problem (I don't know how likely that is in practice...) - there'd be a chain of 10+ Python processes, only the last of which is still useful. It's probably not a massive problem (I assume everything but the last process is paged out) but it's not exactly friendly. OTOH, if you lose the command history and the interpreter state after each install, you'll probably get fed up long before the number of processes is an issue... > It would also be reasonable to say that the regular REPL just issues a > warning that a restart might be needed, and it's only REPLs with a separate > client process that offer a way to restart the subprocess where code > actually executes. This feels awfully like the traditional Windows "your mouse has moved - please reboot to have your changes take effect" behaviour. I don't think we're going to impress many people emulating that :-( Paul _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
