[Python-Dev] PEP 3145 (With Contents)

[Brett Cannon]

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

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

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 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
> >>
> >
> >
> > _______________________________________________
> > 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/chris.jerdonek%40gmail.com
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20121220/9f1da9a1/attachment.html>