[Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

["Martin v. Löwis"]

> 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