<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
Hi.<div><br></div><div>I extended Jeff Hardy's 2008 version of subprocess.py (<a href="http://bitbucket.org/jdhardy/code/src/tip/subprocess.py" style="text-indent: 0px !important; ">http://bitbucket.org/jdhardy/code/src/tip/subprocess.py</a>) module to support (among other things):</div><div>- Redirect to stderr and stdout to file-likes and file descriptors (.Net threads, one per output / input type) On large output sizes, speed is on par with cPython's version.</div><div>- Binary subprocess output capture</div><div>- Implemented .communicate()</div><div>- Added a non-spec .communicateIO() that behaves like .communicate(), but:</div><div> - persists captured data to disk (tempfile.TemporaryFile()) after a custom-defined max on MemoryStream size is reached.</div><div> - outputs out, and err as file-likes, not strings</div><div><br></div><div>Code is here: <a href="http://github.com/dvdotsenko/IronPythonParts">http://github.com/dvdotsenko/IronPythonParts</a> Target functionality is cPython 2.6.x subprocess.py</div><div><br></div><div>.communicateIO() method was added to support to support binary, big outputs from the subprocess. I have a patch / module extension for cPython's version subprocess.py and contemplating submitting it for inclusion along 3.3 timeline, of 3.2 if there is time, help and support for that.</div><div><br></div><div>1. I would appreciate some input on the efficiency of the redirect I am using in _StreamRedirector and _StreamPersistor classes. Because the output must be consumable by "regular" python code, expecting cPython file-like methods on the object, I had a choice of (a) milking data from process.StandardOutput.BaseStream to .Net stream and, then, converting it to file-like or (b) milking the output directly into python file-like, while reboxing Array[Byte] data. I chose the latter. </div><div> (A) is faster than comparable functionality in cPython, but: the resulting file-like does not autodelete itself after f.close() and it would work only in case of .communicate(), as redirect to file-like already gives me a python-style file-like.</div><div> (B) is slightly slower than comparable functionality in cPython, but allows this module to support any type or subclass of any Python file-like, as there is only one requirement - .write() method that takes bytes- or buffer-like input.</div><div>For a second i thought that any give python file-like could in actuality be some sort of .Net stream and was contemplating obtaining a pointer to that .Net "base stream" and writing to it in .Net style. However, realized that some mmaped python file-likes would be implemented on top of byte arrays that are not "streams" so gave up on that idea. </div><div>The only thing i see as possible to improve is finding the fastest way to blip .Net Array[byte] into python file-like that is not necessarily a file. <- Tips on this appreciated.</div><div><br></div><div>2. I am unittesting against cPython 2.6.x's version of test_subprocess.py. They have a bit of "let's see if we are losing pointers, file descriptors" checks in there. Was wondering if IronPython would have similar but different gunk that needs to be checked. I am hoping that I don't need to del MemoryStream objects after .Close() etc. If a good eye could take a brief look at the code with intention of finding leaks, I would sincerely appreciate that.</div><div><br></div><div>Daniel</div> </body>
</html>