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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4