This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pjenvey
Recipients pjenvey
Date 2007-09-22.00:33:36
SpamBayes Score 0.0018934488
Marked as misclassified No
Message-id <1190421217.52.0.890075732591.issue1188@psf.upfronthosting.co.za>
In-reply-to
Content
tell() will skip the next LF (after a CR sets f_skipnextlf) when 
universal newline support is enabled; essentially doing part of the work 
of read(). However it does not identify CRLF as a newline, as read() 
would, e.g.:

>>> open('/tmp/crlf', 'wb').write('CRLF\r\nEOF')
>>> fp = open('/tmp/crlf', 'U')
>>> fp.read()
'CRLF\nEOF'
>>> fp.newlines # correct when read()ing
'\r\n'
>>> fp = open('/tmp/crlf', 'U')
>>> fp.readline()
'CRLF\n'
>>> fp.newlines
>>> fp.tell()
6L
>>> fp.newlines # tell() skipped ahead..
>>> fp.readline()
'EOF'
>>> fp.newlines # ..but never identified CRLF
>>> 

The following patch makes tell() mark CRLF as a newline in this case, 
and ensures so with an added test to test_univnewlines.py. It's against 
trunk, r28227
Files
File name Uploaded
univnewline_tell-r58227.diff pjenvey, 2007-09-22.00:33:36
History
Date User Action Args
2007-09-22 00:33:38pjenveysetspambayes_score: 0.00189345 -> 0.0018934488
recipients: + pjenvey
2007-09-22 00:33:37pjenveysetspambayes_score: 0.00189345 -> 0.00189345
messageid: <1190421217.52.0.890075732591.issue1188@psf.upfronthosting.co.za>
2007-09-22 00:33:37pjenveylinkissue1188 messages
2007-09-22 00:33:37pjenveycreate