> 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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4