On Sun, Dec 9, 2012 at 7:17 AM, Gregory P. Smith <greg at krypto.org> wrote: > I'm really not sure what this PEP is trying to get at given that it > contains no examples and sounds from the descriptions to be adding a > complicated api on top of something that already, IMNSHO, has too much it > (subprocess.Popen). > > Regardless, any user can use the stdout/err/in file objects with their own > code that handles them asynchronously (yes that can be painful but that is > what is required for _any_ socket or pipe I/O you don't want to block on). > And how to use stdout/stderr/in asynchronously in cross-platform manner? IIUC the problem is that every read is blocking. > It *sounds* to me like this entire PEP could be written and released as a > third party module on PyPI that offers a subprocess.Popen subclass adding > some more convenient non-blocking APIs. That's where I'd start if I were > interested in this as a future feature. > I've rewritten the PEP based on how do I understand the code. I don't know how to update it and how to comply with open documentation license, so I just attach it and add PEPs list to CC. Me too has a feeling that the PEP should be stripped of additional high level API until low level functionality is well understood and accepted. -- anatoly t. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20121220/c20409fa/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: pep-3145.diff Type: application/octet-stream Size: 9273 bytes Desc: not available URL: <http://mail.python.org/pipermail/python-dev/attachments/20121220/c20409fa/attachment.obj>
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