By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,742 Members | 1,224 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,742 IT Pros & Developers. It's quick & easy.

Problem with .next() method adding junk characters.

P: n/a
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
Share this Question
Share on Google+
6 Replies


P: n/a

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

P: n/a

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

P: n/a
"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

P: n/a
"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

P: n/a

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

P: n/a

"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.