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

Peter Astrand astrand at lysator.liu.se
Wed Aug 4 21:10:58 CEST 2004

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

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>

More information about the Python-Dev mailing list