RE: [Python-Dev] Re: PEP 324: popen5 - New POSIX process module
On Sat, 3 Jan 2004, Peter Åstrand wrote:
PEP 324: popen5 - New POSIX process module [...] There are some issues wrt Windows support. Currently, popen5 does not support Windows at all. To be able to do so, we must chose between:
1) Rely on Mark Hammonds Win32 extensions. [...] or 2) [...] copy the required process handling functions from win32all
I STRONGLY support doing ONE of these so that popen5 (gee... we gotta get a better name) works "on all major platforms". Ideally, it would work "out of the box", ie, on all sane installations. Personally, I think managing an extra copy of the code would be a bit of a pain, so I would probably prefer (1) (rely on win32all). But that means that people who write simple cross-platform scripts and utilities can't really use popen5 and expect things to work. (I'm not worried about people who write whole applications in Python... they can go ahead and require win32all or ensure it gets loaded. But if I'm writing some short utility scripts or, worse yet, writing code to be published in a magazine or journal and typed in / downloaded by random users, then I am strongly urged to use only completely portable code.) So I guess I am forced to put up with (2), and the (hopefully minor) headaches of copying Mark's code UNLESS we can somehow ensure that win32all is available on all sane windows installs. If, for instance, it were released with the python.org releases for the Windows platform, (other packagers already include it), then I think we could dispense with the annoying need to duplicate code. -- Michael Chermside
At 05-01-2004 15:11, Michael Chermside wrote:
So I guess I am forced to put up with (2), and the (hopefully minor) headaches of copying Mark's code UNLESS we can somehow ensure that win32all is available on all sane windows installs. If, for instance, it were released with the python.org releases for the Windows platform, (other packagers already include it), then I think we could dispense with the annoying need to duplicate code.
A number of people seem to under the impression that win32all contains a lots of useful value added code. It does not. It is a very thin SWIG wrapper over the windows API that it exposes. There is nothing that you will need to copy from it to implement popen5 in C. Just as you would not copy code from the python posix module to implement popen5 in C on Unix. The value of using win32all would be that you could implement popen5 in python rather then C. This might be a good way to develop and test the win32 popen5 algorithms before conversion to C. Developing the algorithm is going to be the hard part. The issue is a packaging one not a code cloning one. 1) include win32all in the standard windows python and implement popen5 in python 2) implement popen5 in C on windows. As I understand it (2) is the suggested way forwards. Barry
At 05-01-2004 15:11, Michael Chermside wrote:
So I guess I am forced to put up with (2), and the (hopefully minor) headaches of copying Mark's code UNLESS we can somehow ensure that win32all is available on all sane windows installs. If, for instance, it were released with the python.org releases for the Windows platform, (other packagers already include it), then I think we could dispense with the annoying need to duplicate code.
A number of people seem to under the impression that win32all contains a lots of useful value added code. It does not. It is a very thin SWIG wrapper over the windows API that it exposes. There is nothing that you will need to copy from it to implement popen5 in C. Just as you would not copy code from the python posix module to implement popen5 in C on Unix.
The value of using win32all would be that you could implement popen5 in python rather then C. This might be a good way to develop and test the win32 popen5 algorithms before conversion to C. Developing the algorithm is going to be the hard part.
The issue is a packaging one not a code cloning one.
1) include win32all in the standard windows python and implement popen5 in python 2) implement popen5 in C on windows.
As I understand it (2) is the suggested way forwards.
Barry
Hm. I'd much rather see a pure Python implementation. This doesn't seem to be something that's particularly performance critical. Starting a process takes so many OS resources that the overhead of doing it in Python is negligeable. I expect only a very small number of win32all entry points to be needed in order to implement popen5, and those we can implement in a separate C module (just as we did for _winreg, which roughly duplicates the registry access API from win32all). --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (3)
-
Barry Scott -
Guido van Rossum -
Michael Chermside