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

[Peter Astrand]

> > 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.

The best way, IMHO, is to use select() on POSIX systems and threads on
Windows. This is what my module 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 see what you mean. My module actually supports passing all types of
flags to CreateProcess, including CREATE_NEW_CONSOLE, so I would say that
my module deals with these issues. Well, I don't have any special boolean
flag or something like that for this specific case, but I see no reason
to.


> > 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".

I don't really see what we could gain from merging our modules. What we
have now is two different modules with two different APIs, and
applications which uses these. If we were to merge our modules, then
the API of either your, mine or both modules would have to change, which
means that the applications using these would not work with the merged
module.

I'm positive to cooperating with you, and perhaps borrow code and ideas
from your module though (and you can of course borrow from mine).


/Peter Åstrand <astrand at lysator.liu.se>