[issue15543] central documentation for 'universal newlines'

Éric Araujo added the comment: Great patch! -- nosy: +eric.araujo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[issue15543] central documentation for 'universal newlines'

Andrew Svetlov added the comment: Yes, it is processed correctly. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscr

[issue15543] central documentation for 'universal newlines'

Chris Jerdonek added the comment: Thanks, David! Also, can/did you check that reflows like these still link to the glossary correctly? + :func:`input` function to allow opening files in binary or :term:`universal + newlines` mode. Another new parameter, *openhook*, lets you use a function

[issue15543] central documentation for 'universal newlines'

Andrew Svetlov added the comment: Good work. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyt

[issue15543] central documentation for 'universal newlines'

R. David Murray added the comment: Thanks Chris. -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed type: -> enhancement ___ Python tracker __

[issue15543] central documentation for 'universal newlines'

Roundup Robot added the comment: New changeset 273df9789796 by R David Murray in branch '3.2': #15543: glossary entry for and 'universal newlines', and links to it. http://hg.python.org/cpython/rev/273df9789796 New changeset e67042b6ad02 by R David Murray in branch '3.2': #15543: reflow paragrap

[issue15543] central documentation for 'universal newlines'

Chris Jerdonek added the comment: And here are the 3.2 patch and the 3.3 "delta" after forward-porting. Note that to forward-port the 3.2 patch to the default 3.3 branch, you can simply drop the changes to the file Doc/library/bz2.rst. I think that is the only conflict. -- Added fil

[issue15543] central documentation for 'universal newlines'

Changes by Chris Jerdonek : Added file: http://bugs.python.org/file26826/issue-15543-6-py32.patch ___ Python tracker ___ ___ Python-bugs-list

[issue15543] central documentation for 'universal newlines'

Chris Jerdonek added the comment: Here is the patch for 2.7. -- Added file: http://bugs.python.org/file26822/issue-15543-6-py27.patch ___ Python tracker ___ _

[issue15543] central documentation for 'universal newlines'

Chris Jerdonek added the comment: Sure, I'd be happy to do both 2.7 and 3.2. I can upload the patch for the default branch as a delta to apply after the 3.2 change has been forward-ported from 3.2 to default. Thanks for taking an interest in this! -- versions: +Python 2.7, Python 3.2

[issue15543] central documentation for 'universal newlines'

R. David Murray added the comment: Yeah, we might as well be consistent, though it's not a big deal either way. I'd prefer that as a separate patch. Any interest in backporting this to 2.7? Being so close to final release on 3.2 I think we can skip 3.2, unless you feel like doing it. --

[issue15543] central documentation for 'universal newlines'

Chris Jerdonek added the comment: Updating patch to tip again. -- Added file: http://bugs.python.org/file26799/issue-15543-5.patch ___ Python tracker ___

[issue15543] central documentation for 'universal newlines'

Chris Jerdonek added the comment: Here is a new patch with David's suggested change (just for doc files though). -- Added file: http://bugs.python.org/file26796/issue-15543-4.patch ___ Python tracker __

[issue15543] central documentation for 'universal newlines'

Chris Jerdonek added the comment: Is it worth standardizing on "universal newlines mode" in the code as well (docstrings, etc)? There are about ten occurrences of "universal newline mode" that would need to be changed. -- ___ Python tracker

[issue15543] central documentation for 'universal newlines'

Chris Jerdonek added the comment: Sure, you're welcome. And sounds good, I'll change it. The singular was the prevailing form, but you're right that there is no reason we can't change it. -- ___ Python tracker _

[issue15543] central documentation for 'universal newlines'

R. David Murray added the comment: Thanks for working on this. I see nothing wrong with using 'universal newlines mode' as the term, which would simplify the markup. -- nosy: +r.david.murray ___ Python tracker __

[issue15543] central documentation for 'universal newlines'

Chris Jerdonek added the comment: Updating patch to latest again. -- nosy: +asvetlov Added file: http://bugs.python.org/file26792/issue-15543-3.patch ___ Python tracker ___ _

[issue15543] central documentation for 'universal newlines'

Chris Jerdonek added the comment: Updating patch to current tip. -- Added file: http://bugs.python.org/file26714/issue-15543-2.patch ___ Python tracker ___ __

[issue15543] central documentation for 'universal newlines'

Chris Jerdonek added the comment: Attaching a patch for review. -- keywords: +patch stage: -> patch review Added file: http://bugs.python.org/file26706/issue-15543-1.patch ___ Python tracker __

[issue15543] central documentation for 'universal newlines'

Chris Jerdonek added the comment: > On the other hand, the details of the *newline* argument should probably > remain in the API descriptions themselves. Correct. It would be a high-level entry for "universal newlines" -- independent of any API and suitable for linking to wherever universal n

[issue15543] central documentation for 'universal newlines'

Antoine Pitrou added the comment: > I nosied you only because you copy and pasted information about > universal newlines that might benefit from a glossary entry or some > such about universal newlines. Yes, it might benefit from a glossary entry. On the other hand, the details of the *newline*

[issue15543] central documentation for 'universal newlines'

Chris Jerdonek added the comment: > There may (or may not :-)) be a misunderstanding. Universal newlines are not > discouraged; it's the legacy "U" flag which is deprecated. Already understood. :) (I said "in the built-in open() function" above and meant "mode" as in "flag".) I nosied you on

[issue15543] central documentation for 'universal newlines'

Antoine Pitrou added the comment: > Since universal newline mode is discouraged and getting deprecated in > the built-in open() function There may (or may not :-)) be a misunderstanding. Universal newlines are not discouraged; it's the legacy "U" flag which is deprecated. -- _

[issue15543] central documentation for 'universal newlines'

Chris Jerdonek added the comment: See also: f17a1410ebe5 -- nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue15543] central documentation for 'universal newlines'

Chris Jerdonek added the comment: Since universal newline mode is discouraged and getting deprecated in the built-in open() function, the "central" place for describing universal newlines should probably not be the documentation for the open() method. I am leaning towards a glossary entry. T

[issue15543] central documentation for 'universal newlines'

Serhiy Storchaka added the comment: See issue15204. -- nosy: +storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue15543] central documentation for 'universal newlines'

New submission from Chris Jerdonek: "Universal newlines" of PEP 278 does not seem to have a central, linkable description within the documentation. In particular, there does not seem to be a glossary entry or any index entries for it. The main documentation seems to be in the middle of the do