The 'help' command, under a win32 console app, separates
lines with \n instead of \r\n as it has in the past,
making its
output a little hard to follow. Possibly an unintended
side effect
of the 'universal newline' addition?

Python 2.3a1 (#38, Dec 31 2002, 17:53:59) [MSC v.1200
32 bit (Intel)] on win32

(windows 98)

Logged In: YES 
user_id=292741

Tracked this down to a change in pydoc.py:
---------------- 2.2.2 -------------------------
def tempfilepager(text, cmd):
    import tempfile
    filename = tempfile.mktemp()
    file = open(filename, 'w')
    file.write(text)
    file.close()
------------------2.3 -------------------------
def tempfilepager(text, cmd):
    import tempfile
    (fd, filename) = tempfile.mkstemp()
    file = os.fdopen(fd, 'w')
    file.write(text)
    file.close()
------------------------------------------------
It seems the use of fdopen means that \n's don't
get  changed to \r\n when the file is written, even though
'w' is used. Whether this should be fixed by modding this
code, or whether this is a fdopen bug, I don't know.

Logged In: YES 
user_id=33168

Looking at the code, I don't see any problems.  I'm guessing
this may be a windows issue.  Universal newlines only seems
to affect reading, so shouldn't be an issue.  Hopefully Tim
has time, interest, and a clue, since I don't.  Tim, do you
know if there is a difference between fopen() and fdopen()
on windows?

Logged In: YES 
user_id=31435

Neal, yes, it's not even possible for fdopen() to create a 
text-mode file on WIndows, and text mode is needed to get 
the \r\n line ends Windows needs for readability.  
Presumably life on Macs is also screwed by this.

Greg, I reverted the code to the "pre-security craze" 
version.  If someone thinks opening a help file for output is a 
security hole, they can waste their time scratching their 
own paranoid itches <wink>.

Lib/pydoc.py; new revision: 1.75