On 22/03/2011 12:04 AM, Paul Moore wrote:
I haven't had time to read the PEP yet, so my apologies if this is
made explicit there, but is the launcher expected to be solely for
implementing file associations? I thought there had been discussions
of using it to start the interactive interpreter, an
On 21 March 2011 01:54, Mark Hammond wrote:
> ie, let's say we are forced to choose between the following 3 options:
>
> * No launcher at all (the status-quo), causing demonstrable breakage in
> Windows file associations whenever Python 2.x and Python 3.x scripts exist
> on the same box.
>
> * An
On Mon, Mar 21, 2011 at 5:16 PM, Mark Hammond wrote:
> On 21/03/2011 1:04 PM, "Martin v. Löwis" wrote:
>>
>> Can you please add a summary of this discussion to
>> the PEP? (also, can you please check in the PEP, and
>
>> give it a number?)
>
> OK, I'll check it in once I get a PEP number allocated
On 21/03/2011 1:04 PM, "Martin v. Löwis" wrote:
Can you please add a summary of this discussion to
the PEP? (also, can you please check in the PEP, and
> give it a number?)
OK, I'll check it in once I get a PEP number allocated as per PEP1,
updated to reflect some of the discussions in this th
On 21/03/2011 3:50 PM, Greg Ewing wrote:
Martin v. Löwis wrote:
Windows doesn't support exec.
Hmmm. In that case, if the launcher works by loading a pythonXY.dll,
I'd say that sys.executable should point to whatever version of
python.exe corresponds to that dll.
Generally, things should be m
Martin v. Löwis wrote:
Windows doesn't support exec.
Hmmm. In that case, if the launcher works by loading a pythonXY.dll,
I'd say that sys.executable should point to whatever version of
python.exe corresponds to that dll.
Generally, things should be made to look as much as possible as
if that
On Sun, Mar 20, 2011 at 6:27 PM, "Martin v. Löwis" wrote:
>
> I'm primarily bothered about the failure to implement TerminateProcess
> correctly. I don't actually know what use cases would be affected, other
> then saying that anything launching py.exe could be affect, in
> particular applications
> I personally would conclude that the last option is the least worst
> scenario by a wide margin.
Ok, I let this rest. Can you please add a summary of this discussion to
the PEP? (also, can you please check in the PEP, and give it a number?)
Thanks,
Martin
___
On 21/03/2011 12:27 PM, "Martin v. Löwis" wrote:
I remain -1 on any proposal that uses subprocesses. It absolutely must
be the launcher that is running Python. In fact, I'd call it
"python.exe".
For clarity, could you please tell us which scenarios you have in mind
that cause you to take that p
>> I remain -1 on any proposal that uses subprocesses. It absolutely must
>> be the launcher that is running Python. In fact, I'd call it
>> "python.exe".
>
> For clarity, could you please tell us which scenarios you have in mind
> that cause you to take that position, and why those scenarios coul
On 21/03/2011 11:15 AM, "Martin v. Löwis" wrote:
Am 21.03.2011 00:43, schrieb Greg Ewing:
Mark Hammond wrote:
The above raises an interesting question - if the launcher executed
Python in-process, what would sys.executable be?
I think it should be the actual Python executing at that
moment,
On 3/20/2011 6:35 PM, Westley Martínez wrote:
On Sun, 2011-03-20 at 05:36 -0400, Terry Reedy wrote:
As both a writer and reader, I would like to just add, for instance,
#! python3
(or 3.3 or whatever) and have the launcher do the 'right thing'.
It seems to me that that really should be enoug
>> In addition to Martin's point, this approach would mean the exit code
>> of the child process probably isn't available to whoever started the
>> launcher.
>
> Maybe I've missed something in this discussion, but is there
> any reason the launcher can't just exec the relevant python?
Windows doe
On 21/03/2011 11:10 AM, "Martin v. Löwis" wrote:
Am 21.03.2011 00:52, schrieb Mark Hammond:
On 21/03/2011 10:32 AM, "Martin v. Löwis" wrote:
The above raises an interesting question - if the launcher executed
Python in-process, what would sys.executable be? I can imagine there
are few scenario
Mark Hammond wrote:
In addition to Martin's point, this approach would mean the exit code of
the child process probably isn't available to whoever started the
launcher.
Maybe I've missed something in this discussion, but is there
any reason the launcher can't just exec the relevant python?
Th
Am 21.03.2011 00:43, schrieb Greg Ewing:
> Mark Hammond wrote:
>
>> The above raises an interesting question - if the launcher executed
>> Python in-process, what would sys.executable be?
>
> I think it should be the actual Python executing at that
> moment, not the launcher. This is the least ch
Am 21.03.2011 00:52, schrieb Mark Hammond:
> On 21/03/2011 10:32 AM, "Martin v. Löwis" wrote:
>>> The above raises an interesting question - if the launcher executed
>>> Python in-process, what would sys.executable be? I can imagine there
>>> are few scenarios where it would be desirable to have i
>> #! python3
[...]
> That would break the whole point of platform-independence.
a) the PEP makes no point about platform-independence.
it is a pure Windows thing, and has no stated objective
to being platform-independent. So loss of platform-independence
may not be deliberate, but is cer
On 21/03/2011 10:32 AM, "Martin v. Löwis" wrote:
The above raises an interesting question - if the launcher executed
Python in-process, what would sys.executable be? I can imagine there
are few scenarios where it would be desirable to have it refer to the
launcher and a number of scenarios where
Mark Hammond wrote:
The above raises an interesting question - if the launcher executed
Python in-process, what would sys.executable be?
I think it should be the actual Python executing at that
moment, not the launcher. This is the least change from
current behaviour and therefore least likely
On Sun, 20 Mar 2011 15:35:02 -0700, Westley =?ISO-8859-1?Q?Mart=EDnez?=
wrote:
> On Sun, 2011-03-20 at 05:36 -0400, Terry Reedy wrote:
> > On 3/20/2011 3:22 AM, Glenn Linderman wrote:
> > On 3/19/2011 7:38 PM, Mark Hammond wrote:
> > [snip]
> >
> > As both a writer and reader, I would like to ju
> The above raises an interesting question - if the launcher executed
> Python in-process, what would sys.executable be? I can imagine there
> are few scenarios where it would be desirable to have it refer to the
> launcher and a number of scenarios where it would be undesirable and
> possibly bre
On Sun, 2011-03-20 at 05:36 -0400, Terry Reedy wrote:
> On 3/20/2011 3:22 AM, Glenn Linderman wrote:
> On 3/19/2011 7:38 PM, Mark Hammond wrote:
> [snip]
>
> As both a writer and reader, I would like to just add, for instance,
>
> #! python3
>
> (or 3.3 or whatever) and have the launcher do the
On Sun, Mar 20, 2011 at 1:56 PM, "Martin v. Löwis" wrote:
> So if somebody would launch a python script with py.exe, they would
> think it was completed even though it would still be running.
Yes py.exe exits way before the python script, but the console stays
open, though now that I test it by r
On 20/03/2011 11:56 PM, Dj Gilcrease wrote:
...
Before Mark wrote up this pep I had started experimenting with how to
make the launcher and I was able to get it to launch python while
exiting py.exe and as far as I could tell it behaved just as if I had
launched the app directly by double clickin
Following up myself here...
On 20/03/2011 9:25 PM, Mark Hammond wrote:
On 20/03/2011 8:37 PM, "Martin v. Löwis" wrote:
...
Some of these uses probably shouldn't use the launcher directly - eg,
ISAPI apps and COM objects which have a separate registration step could
register a specific python.exe
On 20/03/2011 09:58, Mark Hammond wrote:
On 20/03/2011 8:36 PM, Terry Reedy wrote:
On 3/20/2011 3:22 AM, Glenn Linderman wrote:
On 3/19/2011 7:38 PM, Mark Hammond wrote:
[snip]
As both a writer and reader, I would like to just add, for instance,
#! python3
(or 3.3 or whatever) and have the la
> Before Mark wrote up this pep I had started experimenting with how to
> make the launcher and I was able to get it to launch python while
> exiting py.exe and as far as I could tell it behaved just as if I had
> launched the app directly by double clicking it.
In this code, py.exe terminates way
On 20 March 2011 09:58, Mark Hammond wrote:
> On 20/03/2011 8:36 PM, Terry Reedy wrote:
>>
>> On 3/20/2011 3:22 AM, Glenn Linderman wrote:
>> On 3/19/2011 7:38 PM, Mark Hammond wrote:
>> [snip]
>>
>> As both a writer and reader, I would like to just add, for instance,
>>
>> #! python3
>>
>> (or 3.
On Sun, Mar 20, 2011 at 5:37 AM, "Martin v. Löwis" wrote:
> 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 ac
Terry Reedy writes:
> As both a writer and reader, I would like to just add, for instance,
>
> #! python3
>
> (or 3.3 or whatever) and have the launcher do the 'right thing'. It
> seems to me that that really should be enough info for *nix,
For clarity: the reason it's not enough information is
On 20/03/2011 8:37 PM, "Martin v. Löwis" wrote:
...
... problems with creating child processes:
- 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.
Some of these uses probably shouldn
On 20/03/2011 8:36 PM, Terry Reedy wrote:
On 3/20/2011 3:22 AM, Glenn Linderman wrote:
On 3/19/2011 7:38 PM, Mark Hammond wrote:
[snip]
As both a writer and reader, I would like to just add, for instance,
#! python3
(or 3.3 or whatever) and have the launcher do the 'right thing'.
If there wa
>>> 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 togeth
> 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
On 3/20/2011 3:22 AM, Glenn Linderman wrote:
On 3/19/2011 7:38 PM, Mark Hammond wrote:
[snip]
As both a writer and reader, I would like to just add, for instance,
#! python3
(or 3.3 or whatever) and have the launcher do the 'right thing'.
It seems to me that that really should be enough info fo
On 20/03/2011 6:22 PM, Glenn Linderman wrote:
On 3/19/2011 7:38 PM, Mark Hammond wrote:
...
A Windows user who has only learned Python 2.x programming would not
necessarily have ever heard of execve, would not realize execve(2) means
it is from the 2nd chapter of the Unix man pages, meaning an
On 3/19/2011 7:38 PM, Mark Hammond wrote:
Thanks for the feedback!
And thanks for more complete explanations.
Sadly I was offline when writing my first response, and couldn't view
the man page for execve you referred to. Having just read it, I think
it would be total gibberish to a Windows
On Sun, Mar 20, 2011 at 3:46 PM, Scott Dial
wrote:
> 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-lin
On 3/19/2011 7:23 PM, Nick Coghlan wrote:
> On Sun, Mar 20, 2011 at 9:04 AM, "Martin v. Löwis" wrote:
>> Am 19.03.2011 23:51, schrieb Nick Coghlan:
>>> On Sun, Mar 20, 2011 at 4:49 AM, "Martin v. Löwis"
>>> wrote:
I, for example, will find issues with it if the implementation uses
Crea
> Out of curiosity, what is your objection to having the child process?
One of the problems is that parent process will not be able to kill
launched script. Simply doing TerminateProcess will kill the launcher,
leaving interpreter running. This can be partially fixed with job
objects, though.
Eug
On 20/03/2011 5:49 AM, "Martin v. Löwis" wrote:
* Is this really PEP material, or will turning the PEP into a regular
spec be suitable?
It's PEP material if it is contentious, which I believe it is.
Of course it is - this is python-dev .
I, for example, will find issues with it if the imple
On 20/03/2011 4:15 AM, Dj Gilcrease wrote:
On Sat, Mar 19, 2011 at 4:44 AM, Glenn Linderman wrote:
2) If the launcher provides command line options for the "benefit" of
launching interactive Python interpreters, those command line options can
have data puns with script names, or can conflict
Thanks for the feedback!
On 19/03/2011 7:44 PM, Glenn Linderman wrote:
Not all of the ideas below are complementary to each other, some are
either or, to allow different thoughts to be inspired or different
directions to be taken.
Thanks for starting a PEP.
On 3/18/2011 11:02 PM, Mark Hammond
On Sun, Mar 20, 2011 at 9:04 AM, "Martin v. Löwis" wrote:
> Am 19.03.2011 23:51, schrieb Nick Coghlan:
>> On Sun, Mar 20, 2011 at 4:49 AM, "Martin v. Löwis"
>> wrote:
>>> I, for example, will find issues with it if the implementation uses
>>> CreateProcess at some point - the launcher should IMO
Am 19.03.2011 23:51, schrieb Nick Coghlan:
> On Sun, Mar 20, 2011 at 4:49 AM, "Martin v. Löwis" 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, i
On Sun, Mar 20, 2011 at 4:49 AM, "Martin v. Löwis" 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 act
> * Is this really PEP material, or will turning the PEP into a regular
> spec be suitable?
It's PEP material if it is contentious, which I believe it is.
I, for example, will find issues with it if the implementation uses
CreateProcess at some point - the launcher should IMO run Python
directly,
On Sat, Mar 19, 2011 at 4:44 AM, Glenn Linderman wrote:
> The launcher could be simpler if the Python installer placed versioned
> Python executables on the PATH. Unfortunately, historically it hasn't. If
> it did, would, or the launcher installer would place them there for
> pre-existing versio
Not all of the ideas below are complementary to each other, some are
either or, to allow different thoughts to be inspired or different
directions to be taken.
Thanks for starting a PEP.
On 3/18/2011 11:02 PM, Mark Hammond wrote:
The launcher should be as simple as possible (but no simp
Hi all,
During the huge thread about PEP 394, a suggestion was made that a
"launcher" for Python on Windows could be implemented which would allow
for some of the guidelines in that PEP to apply to the Windows version
of Python.
I've attached the first draft of a PEP for such a launcher and
51 matches
Mail list logo
