What should I do in case Eric lost interest after his GSoC project for PSF appeared as useless for python-dev community? Should I rewrite the proposal from scratch?
On Thu, Dec 20, 2012 at 11:18 PM, Brett Cannon <br...@python.org> wrote: > 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 <techto...@gmail.com>wrote: > >> On Sun, Dec 9, 2012 at 7:17 AM, Gregory P. Smith <g...@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. >> >> _______________________________________________ >> 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 >> >> >
_______________________________________________ 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/archive%40mail-archive.com
