(original) (raw)

On Thu, Dec 20, 2012 at 3:55 PM, Chris Jerdonek <chris.jerdonek@gmail.com> wrote:

On Thu, Dec 20, 2012 at 12:18 PM, Brett Cannon <brett@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@python.org> (no cross-posting

please). Also see PEP Editor Responsibilities & Workflow below."

as well as:

"A PEP editor must subscribe to the <peps@python.org> list. All

PEP-related correspondence should be sent (or CC'd) to

<peps@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.)

But it very clearly states to NOT cross-post which is exactly what Anatoly did and that is what I take issue with the most. I personally don't see any confusion with the wording. It clearly states that if you are a PEP author you should mail the peps editors and NOT cross-post. If you are an editor, make sure any emailing you do with an individual CCs the list but do NOT cross-post.

-Brett

\--Chris

\> On Wed, Dec 19, 2012 at 5:20 PM, anatoly techtonik <techtonik@gmail.com>
\> wrote:

>>
\>> On Sun, Dec 9, 2012 at 7:17 AM, Gregory P. Smith <greg@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/chris.jerdonek%40gmail.com
\>