RE: [Python-Dev] Re: PEP 324 (process module)
Guido writes:
I believe ActiveState's Trent Mick has released something along these lines. Does your proposed API match theirs?
Peter replies: [...]
So, the chances of getting our modules API-compatible are very small.
I'll note that my impression is that Peter's module is not aiming to be particularly innovative in terms of implementation, it's primary "feature" is having a decent API. And my impression is that it has been well received on c.l.py (for instance, I often see it recommended in response to newbie questions). He got a lot of input during the PEP process and tried to incorporate it. Last time I tried it there were still a few windows issues (docs say these have been resolved), but I thought the API was well-designed. And popen2 isn't. -- Michael Chermside
Last time I tried it there were still a few windows issues (docs say these have been resolved), but I thought the API was well-designed.
The details: The module works great on Windows currently, but requires the win32all extensions. The idea is to get rid of this dependency by writing a glue module, pretty much as _winreg. Work on such a _process module has been done on two fronts: * A friendly Python-developer has gotten quite far, but was experiencing some strange hangs. I haven't been able to look at this work yet. * I've started working on an implementation myself. I was using _winreg as some sort of template. The problem is: I've never written extension modules before :-) It was quite easy to export the numeric constants, but when I came to creating Python objects, I was lost. I'll guess I need to read some documentation. This is what remains: win32api: GetStdHandle GetCurrentProcess, DuplicateHandle win32pipe: CreatePipe win32process: CreateProcess, STARTUPINFO, GetExitCodeProcess win32event: WaitForSingleObject Here's the module so far: /* _process.c */ #include "windows.h" #include "Python.h" #include "structmember.h" #include "malloc.h" /* for alloca */ /* The win32api module reports the function name that failed, but this concept is not in the Python core. Hopefully it will one day, and in the meantime I dont want to lose this info... */ #define PyErr_SetFromWindowsErrWithFunction(rc, fnname) \ PyErr_SetFromWindowsErr(rc) /* Forward declares */ /* Doc strings */ // FIXME PyDoc_STRVAR(module_doc, "This module provides...\n"); static struct PyMethodDef process_methods[] = { NULL, }; static void insint(PyObject * d, char * name, long value) { PyObject *v = PyInt_FromLong(value); if (!v || PyDict_SetItemString(d, name, v)) PyErr_Clear(); Py_XDECREF(v); } #define ADD_INT(val) insint(d, #val, val) PyMODINIT_FUNC init_process(void) { PyObject *m, *d; m = Py_InitModule3("_process", process_methods, module_doc); d = PyModule_GetDict(m); Py_INCREF(PyExc_WindowsError); if (PyDict_SetItemString(d, "error", PyExc_WindowsError) != 0) return; /* Add the relevant constants */ ADD_INT(DUPLICATE_SAME_ACCESS); ADD_INT(STARTF_USESTDHANDLES); ADD_INT(STD_INPUT_HANDLE); ADD_INT(STD_OUTPUT_HANDLE); ADD_INT(STD_ERROR_HANDLE); ADD_INT(INFINITE); ADD_INT(WAIT_OBJECT_0); } (I will be away for a couple of days.) /Peter Åstrand <astrand@lysator.liu.se>
Michael Chermside <mcherm@mcherm.com> writes:
Guido writes:
I believe ActiveState's Trent Mick has released something along these lines. Does your proposed API match theirs?
Peter replies: [...]
So, the chances of getting our modules API-compatible are very small.
I'll note that my impression is that Peter's module is not aiming to be particularly innovative in terms of implementation, it's primary "feature" is having a decent API. And my impression is that it has been well received on c.l.py (for instance, I often see it recommended in response to newbie questions). He got a lot of input during the PEP process and tried to incorporate it.
Although Peter has been very receptive to feedback, he has some strong design goals (noted in the PEP) which make the resulting module feel too "low level" for me. I'd love to see a function process.filter(cmd, input=None) Execute cmd (if it's a string, use the shell, if it's a list, treat as an argv sequence) and pass it input as stdin (default, no stdin). Return the command's stdout. If an error occurs (either in the exec, or if the command returns a nonzero return code) raise an exception (and capture the stderr in the exception data). This function should deal with deadlock issues. I don't know of *any* process module that makes this "expect it to work" model any easier. And Peter's design constraint of avoiding the shell actively hurts here (although his interact() function is specifically there to avoid the deadlock issues that could otherwise occur with a naive attempt to implement this). It's possible that I could implement this function on top of Trent's module. Must try... Paul. -- "Bother," said the Borg, "We've assimilated Pooh."
participants (3)
-
Michael Chermside -
Paul Moore -
Peter Astrand