Message11907

Author psykiatris
Recipients amit, fwierzbicki, jeff.allen, psykiatris, santa4nt, zyasoft
Date 2018-04-15.13:11:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1523797883.92.0.682650639539.issue2363@psf.upfronthosting.co.za>
In-reply-to
Content
I apologize that this issue is becoming a very long thread. It dawned on me before I woke up this morning realizing that we may be dealing with the behavior of readline() and not the arithmetic, maybe. 

I did find a SeekTellTest in test_fileio, which helped me in drastically reducing my code for the read/readline seek test.

Now to clarify my point: The test.log file consists of 3 lines, ending with a '\n':

Line 1:  101 bytes
Line 2: 4101 bytes : 1 & 2 = 4202
Line 3: 101 bytes  : all lines = 4303

Now, read() reads all, so tell() will return 4303. But, since we limit it to 1024, it will mark position at 1024.

When readline() is called, what happens? It read in lines 1 & 2 and produced a position of 4202 when we called tell(). When we did the seek, it produced an incorrect result in Jython because line 1 (101) was omitted from the calculation. Python passed because line 1 was included.

We have 3 issues:
1. The math is incorrect. (the math passes in Python, fails in Jython)
2. Why did readline() read 2 lines, both of which ends with a newline? (fails in both Python and Jython)
3. Is it important?
My output from Jython:

--- Result of seekreadline() ---

readline() position->  101
Seek back amt-------> -100
New position-------->  200
Wrong position

--- Result of seekboth() ---

read() position------> 1024
readline() position--> 4202
Seek back amt--------> -100
New position---------> 4202
Wrong position
History
Date User Action Args
2018-04-15 13:11:23psykiatrissetmessageid: <1523797883.92.0.682650639539.issue2363@psf.upfronthosting.co.za>
2018-04-15 13:11:23psykiatrissetrecipients: + psykiatris, fwierzbicki, zyasoft, jeff.allen, santa4nt, amit
2018-04-15 13:11:23psykiatrislinkissue2363 messages
2018-04-15 13:11:22psykiatriscreate