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

Peter Astrand astrand at lysator.liu.se
Wed Aug 4 16:05:22 CEST 2004

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. If you get rid of the threads, then you don't need the workaround code for Linux.

Some of the large code size is for execution through the shell. :) I think that execution via the shell should be a feature of a module like this (so that users can use some shell features) and I even think that it should be the default (so that, for example, Windows users don't have to learn what cmd.exe or command.com are to run "dir"). However, I absolutely agree that one should be able to run withOUT the shell (i.e. have an option for this).

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.

Other reasons for the size/complexity of my process.py over yours: - My process objects have a .kill() method -- which is actually quite a pain on Windows.

True. I guess my module would benefit from such a method as well.

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

> * The modules uses destructors, which I'm usually avoiding.

Is that evil?

Destructors interferes with the GC. Someone else can probably fill in the details.

concensus. In the meantime, if you'd be willing to change your module's name to something other than process.py I think that would help discussions. (I don't know if that is a pain for you at this point. You mentioned "subprocess".

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 :-)

Alternatively, how about "posixprocess"? Though, despite PEP 324's title, I don't know if that is completely accurate anymore.)

Oh, I've forgotten to change the title. Yes, this is wrong, because the module certainly aims to work on non-POSIX systems as well (read: Windows).

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

More information about the Python-Dev mailing list