> Out of curiosity, what is your objection to having the child process? I > guess it must be the system resources needed for the parent process > while it waits for the child to terminate so the exit code can be > reflected correctly "up stream"?
I see three problems with creating child processes: - WaitForSingleObject and GetExitProcessCode must work correctly. I think this is possible to achieve - applications using the debug API, PSAPI, etc. will be confused if the action all happens in a child process. I can accept that they have to adjust, though. - TerminateProcess must work correctly, and I see no way to achieve that (i.e. terminating the parent process won't terminate the child) > I would have 3 main problems with dynamically loading Python into the > launcher process: > > * It may be difficult or impossible to do for implementations other than > CPython. That wouldn't bother me. > * There are subtle differences when Python is loaded by an executable in > the "install" directory versus by an executable that is not. > Specifically, I'm thinking about the differences in how the default > sys.path is populated. This would need to be fixed. I.e. the launcher would have to arrange it so it gives the illusion of having been started from the executable. > * The registry doesn't currently tell us exactly where pythonxx.dll can > be located, but does tell is where python.exe is. Thus things would get > a little more complex as we go snooping for the location of the DLL. The launcher can know how all released Python versions behaved, so it can adjust. > Actually, it does say '...the "console" version of the launcher should > be associated with .py files and the "windows" version associated with > .pyw files.' Ah, ok, I missed that. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
