Message 97258 - Python tracker

➜

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	pitrou
Recipients	lucifer, nirai, pitrou
Date	2010-01-05.10:58:26
SpamBayes Score	4.921242e-05
Marked as misclassified	No
Message-id	<[email protected]>
In-reply-to

Content
> Since the peek is called with a value of 2, the newline sequence \r\n > should be retrieved as is. No, it doesn't follow. The \r can still appear at the end of a readahead, in which case your algorithm will not eliminate the following \n. That is, if the sequence of readaheads is ['a\r', '\nb\n'], readlines() will return ['a\n', '\n', 'b\n'] while it should return ['a\n', 'b\n']. It should be possible to construct a statistically valid test case for this, for example by creating an archived file containing 'a\r\n'*10000 and reading back from it.

> Since the peek is called with a value of 2, the newline sequence \r\n
> should be retrieved as is.

No, it doesn't follow. The \r can still appear at the end of a readahead, in which case your algorithm will not eliminate the following \n.

That is, if the sequence of readaheads is ['a\r', '\nb\n'], readlines() will return ['a\n', '\n', 'b\n'] while it should return ['a\n', 'b\n'].

It should be possible to construct a statistically valid test case for this, for example by creating an archived file containing 'a\r\n'*10000 and reading back from it.

History
Date	User	Action	Args
2010-01-05 10:58:28	pitrou	set	recipients: + pitrou, nirai, lucifer
2010-01-05 10:58:28	pitrou	set	messageid: <[email protected]>
2010-01-05 10:58:26	pitrou	link	issue7610 messages
2010-01-05 10:58:26	pitrou	create