[Python-Dev] PEP 3145 (With Contents)

anatoly techtonik techtonik at gmail.com
Mon Dec 24 14:42:20 CET 2012


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 <brett at 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 <techtonik at gmail.com>wrote:
>
>> 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.
>>
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20121224/dc5b0b2a/attachment.html>


More information about the Python-Dev mailing list