On Jun 24, 2004, at 3:16 PM, P at draigBrady.com wrote: > I've written a couple of apps that required > running a command and grabbing the output, > and I've found the existing interfaces problematic for this. > > I think the proliferation of functions and classes > in the popen2 module illustrates the problem > (popen2.{popen2,popen3,popen4,Popen3,Popen4}) > Now if I want to read both stdout and stderr > seperately then it's awkward to say the least > to implement that without deadlocking using > the popen2 module. Also the multiplexing of > stdout and stderr in popen4 and commands.getoutput > is not usually what one requires IMHO. > > There are external solutions like the getCommandOutput recipe: > http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52296 > which has problems that I've commented on there. > There are also very complex solutions like "subproc" from > Ken Manheimer and "task" from Rob Hooft > > Therefore I bit the bullet and wrote my own, > with as simple an interface as I thought possible: > http://www.pixelbeat.org/libs/subProcess.py > > Perhaps this could be included in commands.py for e.g.? There's already a PEP and implementation for a new popen-ish module that supersedes all of them and probably covers all of your needs (I've already used it in several projects and it's worked great): http://www.python.org/peps/pep-0324.html -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2357 bytes Desc: not available Url : http://mail.python.org/pipermail/python-dev/attachments/20040625/255aaaf9/smime.bin
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