[Python-Dev] PEP 3145 (With Contents)
chris.jerdonek at gmail.com
Thu Dec 20 21:55:05 CET 2012
On Thu, Dec 20, 2012 at 12:18 PM, Brett Cannon <brett at python.org> wrote:
> 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.
PEP 1 should perhaps be clarified if the above is the case.
Currently, PEP 1 says all PEP-related e-mail should be sent there:
"The PEP editors assign PEP numbers and change their status. Please
send all PEP-related email to <peps at python.org> (no cross-posting
please). Also see PEP Editor Responsibilities & Workflow below."
as well as:
"A PEP editor must subscribe to the <peps at python.org> list. All
PEP-related correspondence should be sent (or CC'd) to
<peps at python.org> (but please do not cross-post!)."
(Incidentally, the statement not to cross-post seems contradictory if
a PEP-related e-mail is also sent to python-dev, for example.)
> On Wed, Dec 19, 2012 at 5:20 PM, anatoly techtonik <techtonik at gmail.com>
>> 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
>>> 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
>> 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
> Python-Dev mailing list
> Python-Dev at python.org
More information about the Python-Dev