Re: [Python-Dev] [Python-checkins] cpython (3.3): Issue #17860: explicitly mention that std* streams are opened in binary mode by
On Sat, 06 Jul 2013 10:25:19 +0200, ronald.oussoren <python-checkins@python.org> wrote:
IMO, either the default should be mentioned first, or the default should be mentioned in a parenthetical. Otherwise it sounds like newline translation is being done in both modes. Logically that makes no sense, so the above construction will likely lead to, at a minimum, an interruption in the flow for the reader, and at worse even more confusion than not mentioning it at all. --David
On 6 Jul, 2013, at 13:59, R. David Murray <rdmurray@bitdance.com> wrote:
You've got a point there. Converting the next text (", otherwise ...") to a parententical seems to be the cleanest fix, creating a separate sentence for the ``False`` case introduces duplication unless I restructure the text. Ronald
On 6 Jul, 2013, at 14:09, Ronald Oussoren <ronaldoussoren@mac.com> wrote:
I didn't like the parenthentical after all. Would this work for you?: - If *universal_newlines* is ``True``, the file objects *stdin*, *stdout* and - *stderr* will be opened as text streams in :term:`universal newlines` mode + If *universal_newlines* is ``False`` the file objects *stdin*, *stdout* and + *stderr* will be opened as binary streams, and no line ending conversion is done. + + If *universal_newlines* is ``True``, these file objects + will be opened as text streams in :term:`universal newlines` mode using the encoding returned by :func:`locale.getpreferredencoding(False) - <locale.getpreferredencoding>`, otherwise these streams will be opened - as binary streams. For *stdin*, line ending characters + <locale.getpreferredencoding>`. For *stdin*, line ending characters ``'\n'`` in the input will be converted to the default line separator :data:`os.linesep`. For *stdout* and *stderr*, all line endings in the output will be converted to ``'\n'``. For more information see the That is, a new paragraph is added before the existing one to explain the behavior of "not universal_newlines". Ronald
Please update the docstring in subprocess.py with the wording improvements that you settle on while you're at it. On Sat, Jul 6, 2013 at 6:03 AM, Ronald Oussoren <ronaldoussoren@mac.com>wrote:
On 6 Jul, 2013, at 13:59, R. David Murray <rdmurray@bitdance.com> wrote:
You've got a point there. Converting the next text (", otherwise ...") to a parententical seems to be the cleanest fix, creating a separate sentence for the ``False`` case introduces duplication unless I restructure the text. Ronald
On 6 Jul, 2013, at 14:09, Ronald Oussoren <ronaldoussoren@mac.com> wrote:
I didn't like the parenthentical after all. Would this work for you?: - If *universal_newlines* is ``True``, the file objects *stdin*, *stdout* and - *stderr* will be opened as text streams in :term:`universal newlines` mode + If *universal_newlines* is ``False`` the file objects *stdin*, *stdout* and + *stderr* will be opened as binary streams, and no line ending conversion is done. + + If *universal_newlines* is ``True``, these file objects + will be opened as text streams in :term:`universal newlines` mode using the encoding returned by :func:`locale.getpreferredencoding(False) - <locale.getpreferredencoding>`, otherwise these streams will be opened - as binary streams. For *stdin*, line ending characters + <locale.getpreferredencoding>`. For *stdin*, line ending characters ``'\n'`` in the input will be converted to the default line separator :data:`os.linesep`. For *stdout* and *stderr*, all line endings in the output will be converted to ``'\n'``. For more information see the That is, a new paragraph is added before the existing one to explain the behavior of "not universal_newlines". Ronald
Please update the docstring in subprocess.py with the wording improvements that you settle on while you're at it. On Sat, Jul 6, 2013 at 6:03 AM, Ronald Oussoren <ronaldoussoren@mac.com>wrote:
participants (3)
-
Gregory P. Smith -
R. David Murray -
Ronald Oussoren