You cannot rewrite an existing PEP if you are not one of the original owners, nor can you add yourself as an author to a PEP without permission from the original authors.
And please do not CC the peps mailing list on discussions. It should only be used to mail in new PEPs or acceptable patches to PEPs.
On Wed, Dec 19, 2012 at 5:20 PM, anatoly techtonik firstname.lastname@example.org:
On Sun, Dec 9, 2012 at 7:17 AM, Gregory P. Smith email@example.com 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.
Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org