[Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows
Scott Dial
scott+python-dev at scottdial.com
Sun Mar 20 06:46:17 CET 2011
More information about the Python-Dev mailing list
Sun Mar 20 06:46:17 CET 2011
- Previous message: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows
- Next message: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 3/19/2011 7:23 PM, Nick Coghlan wrote: > On Sun, Mar 20, 2011 at 9:04 AM, "Martin v. Löwis" <martin at v.loewis.de> wrote: >> Am 19.03.2011 23:51, schrieb Nick Coghlan: >>> On Sun, Mar 20, 2011 at 4:49 AM, "Martin v. Löwis" <martin at v.loewis.de> wrote: >>>> I, for example, will find issues with it if the implementation uses >>>> CreateProcess at some point - the launcher should IMO run Python >>>> directly, rather than creating a new process. This, in turn, will >>>> probably mean that you cannot actually implement the PEP in Python. >>> >>> runpy performs basically that dance to implement >>> _run_module_as_main(), so it's definitely possible. >> >> Does it also support loading a different interpreter version than the >> one it is running? > > Ouch, no. I guess you're right, any Python based solution will need to > create a child process. Why would that be true? Shouldn't this launcher just be a basic wrapper that cobbles together the arguments for an eventual os.exec*() call? What is there to do other than to exec the correct interpreter with (a subset of?) the command-line arguments? -- Scott Dial scott at scottdial.com scodial at cs.indiana.edu
- Previous message: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows
- Next message: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list