[Python-Dev] Re: PEP 324 (process module)

[Trent Mick]

[Peter Astrand wrote]
> > ProcessProxy:
> >     ...a behemoth using a thread for each of stdin/stdout/stderr to
> >     allow the user to get an event-like IO interface.
> 
> Why not avoid threads on POSIX systems, and use select instead? My module
> does, although it does not provide an event-like IO interface. 

Because that wouldn't be cross-platform... perhaps it would be possible
though. I am not that experienced with select() -- I have generally
eschewed it because I can't use it on Windows as well.

> If you get rid of the threads, then you don't need the workaround code
> for Linux.

Slight misunderstanding there: the separate thread from which you cannot
kill a subprocess on Linux is not one of these ProcessProxy threads.
I.e. ignoring ProcessProxy the LinuxThreads-bug workaround is still
necessary for Process and ProcessOpen for the user that starts a
subprocess on their thread-A and wants to kill it on their thread-B.


> You're right. My module should probably have an option for invoking
> through the shell, or at least document how to do it. I really don't want
> it as default, though.

I have code to find the shell adequately so I don't see why we couldn't
use it. As to making it the default or not: perhaps clear documentation
could help avoid the expected "I can't run 'dir'!" newbie complaint, but
I don't think it would get all of the them. The current popen*() execute
via the shell. The lower-level guys, exec*() and spawn*(), do not. Still
up for debate, I guess. :)


> > - My module includes some handling that for subsystem:windows vs.
> >   subsystem:console apps on Windows that I don't think yours does.
> 
> Can you describe why this is needed/useful?

A subsystem:windows app (like Komodo, or Idle, or pythonw.exe, or any
GUI app) doesn't have a console and hence doesn't have std handles. By
default, executing any subsytem:console app (like 'ls' or 'echo' or
'python' or 'perl) from a subsystem:windows app will result in an
AllocConsole call
(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/allocconsole.asp)
that will result in a console dialog popping up.  You can see this on
some Windows apps that haven't dealt with this issue. In particular,
some installers out there will pop up an unprofessional console dialog
when running some sub-processes.  To avoid this one has to muck around
with CreateProcess options.  Or, kind of the reverse, if a seeming GUI
app *does* have std handles (often redirected to log files, Komodo does
this) and it wants to offer the ability to pop up a console (e.g.
Komodo's feature to debug in a separate console) then one needs the
ability to specify CREATE_NEW_CONSOLE.


> I can change, but I'd like more feedback before that. No-one has told me
> their opinion on the name "subprocess", for example, not even you :-)

Sure, I don't mind "subprocess". I am hoping, though, that we can
eventually merge our two modules and just call that one "process".


Trent

-- 
Trent Mick
TrentM at ActiveState.com