468,244 Members | 1,860 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,244 developers. It's quick & easy.

Problem with .next() method adding junk characters.

Hi,

I tried searching for this and did not find this issue. I only looked
at about dozen hits, I apologize if this is covered somewhere and I
missed it. Without much further ado, here's the thing (Win, Py2.5):
>>f = open('test', 'w')
f.fileno()
4
>>f.write('1\n')
f.write('2\n3\n4\n')
f.next()
Traceback (most recent call last):
File "<pyshell#8>", line 1, in <module>
f.next()
IOError: [Errno 9] Bad file descriptor
>>f.close()
f = open('test')
f.next()
'1\n'
>>f.next()
'2\n'
>>f.next()
'3\n'
>>f.next()
'4\n'
>>f.next()
'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00
....many more lines of junk...'

I'm not actually trying to do something particular, I'm making snippets
of example code for all functions in LibRef and I ran into this, and
I'm just curious as to what's happening. I understand that you're not
supposed to call .next on a file open for writing. But I don't know why
and how it does what happened here; besides, I've seen the same thing
happen before when I was doing something else with file
open/write/close, but I don't remember the specifics.

Oct 2 '06 #1
6 1023

Rainy wrote:
Hi,

I tried searching for this and did not find this issue. I only looked
at about dozen hits, I apologize if this is covered somewhere and I
missed it. Without much further ado, here's the thing (Win, Py2.5):
>f = open('test', 'w')
f.fileno()
4
>f.write('1\n')
f.write('2\n3\n4\n')
f.next()

Traceback (most recent call last):
File "<pyshell#8>", line 1, in <module>
f.next()
IOError: [Errno 9] Bad file descriptor
This *should* complain that the file is not open for reading. What you
see is an accidental error. message. When I tried it, I got no error,
but it printed a few hundred bytes of garbage.
In both your case and mine, it has also written a load of junk to the
file!
>f.close()
f = open('test')
f.next()
'1\n'
>f.next()
'2\n'
>f.next()
'3\n'
>f.next()
'4\n'
>f.next()
'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00
...many more lines of junk...'
Junk was written to the file earlier.
>
I understand that you're not
supposed to call .next on a file open for writing.
Indeed. However if you mess up, Python is supposed to give you a
meaningful error message and not write gibberish to your file.

Please report it as a bug.

Cheers,
John

Oct 2 '06 #2

John Machin wrote:
Rainy wrote:
Hi,

I tried searching for this and did not find this issue. I only looked
at about dozen hits, I apologize if this is covered somewhere and I
missed it. Without much further ado, here's the thing (Win, Py2.5):
>>f = open('test', 'w')
>>f.fileno()
4
>>f.write('1\n')
>>f.write('2\n3\n4\n')
>>f.next()
Traceback (most recent call last):
File "<pyshell#8>", line 1, in <module>
f.next()
IOError: [Errno 9] Bad file descriptor

This *should* complain that the file is not open for reading. What you
see is an accidental error. message. When I tried it, I got no error,
but it printed a few hundred bytes of garbage.
In both your case and mine, it has also written a load of junk to the
file!
>>f.close()
>>f = open('test')
>>f.next()
'1\n'
>>f.next()
'2\n'
>>f.next()
'3\n'
>>f.next()
'4\n'
>>f.next()
'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0 0\x00\x00\x00\x00
...many more lines of junk...'

Junk was written to the file earlier.

I understand that you're not
supposed to call .next on a file open for writing.

Indeed. However if you mess up, Python is supposed to give you a
meaningful error message and not write gibberish to your file.

Please report it as a bug.

Cheers,
John
Thanks for the reply, I reported it..

-Rainy

Oct 2 '06 #3
"Rainy" <ak@silmarill.orgwrote:
I'm just curious as to what's happening. I understand that you're not
supposed to call .next on a file open for writing. But I don't know why
and how it does what happened here; besides, I've seen the same thing
happen before when I was doing something else with file
open/write/close, but I don't remember the specifics.
C's stdio library require you to call "flush" when switching between reading and
writing; if you don't, the result is undefined.

</F>

Oct 2 '06 #4
"Fredrik Lundh" <fr*****@pythonware.comwrote in message
news:ma***************************************@pyt hon.org...
"Rainy" <ak@silmarill.orgwrote:
>I'm just curious as to what's happening. I understand that you're not
supposed to call .next on a file open for writing. But I don't know why
and how it does what happened here; besides, I've seen the same thing
happen before when I was doing something else with file
open/write/close, but I don't remember the specifics.

C's stdio library require you to call "flush" when switching between
reading and
writing; if you don't, the result is undefined.

</F>
Sure enough, following the OP's original sequence, with an intervening flush
between the writes and next, leaves the file in the expected state:
>>f = file("xyzzy.dat","w")
f.write("1\n")
f.write("2\n")
f.write("3\n")
f.flush()
f.next()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
IOError: [Errno 9] Bad file descriptor
>>f.close()
f = file("xyzzy.dat")
f.next()
'1\n'
>>f.next()
'2\n'
>>f.next()
'3\n'
>>f.next()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
StopIteration
>>>
I would guess then that the likely extent of any fix to this "bug" would be
documentation to the effect of Fredrik's last comment above.

-- Paul
Oct 2 '06 #5

Paul McGuire wrote:
"Fredrik Lundh" <fr*****@pythonware.comwrote in message
news:ma***************************************@pyt hon.org...
"Rainy" <ak@silmarill.orgwrote:
I'm just curious as to what's happening. I understand that you're not
supposed to call .next on a file open for writing. But I don't know why
and how it does what happened here; besides, I've seen the same thing
happen before when I was doing something else with file
open/write/close, but I don't remember the specifics.
C's stdio library require you to call "flush" when switching between
reading and
writing; if you don't, the result is undefined.

</F>

Sure enough, following the OP's original sequence, with an intervening flush
between the writes and next, leaves the file in the expected state:
>f = file("xyzzy.dat","w")
f.write("1\n")
f.write("2\n")
f.write("3\n")
f.flush()
f.next()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
IOError: [Errno 9] Bad file descriptor
>f.close()
f = file("xyzzy.dat")
f.next()
'1\n'
>f.next()
'2\n'
>f.next()
'3\n'
>f.next()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
StopIteration
>>

I would guess then that the likely extent of any fix to this "bug" would be
documentation to the effect of Fredrik's last comment above.

-- Paul
Thanks.. I get it now. Should I close the bug report then?

Oct 2 '06 #6

"Rainy" <ak@silmarill.orgwrote in message
news:11*********************@e3g2000cwe.googlegrou ps.com...
>
Paul McGuire wrote:
>I would guess then that the likely extent of any fix to this "bug" would
be
documentation to the effect of Fredrik's last comment above.

Thanks.. I get it now. Should I close the bug report then?
Either that, or change it to a doc bug and suggest the addition to the
beginning of the second paragraph of
"When switching from reading or writing (or vice versa), call flush(), or
the result will be undefined."

Terry Jan Reedy

Oct 3 '06 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

9 posts views Thread by tym | last post: by
2 posts views Thread by Tomek R. | last post: by
2 posts views Thread by ajikoe | last post: by
9 posts views Thread by mikelbell2000 | last post: by
10 posts views Thread by Markus Svilans | last post: by
4 posts views Thread by situ | last post: by
reply views Thread by NPC403 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.