Problem with .next() method adding junk characters.

Discussion in 'Python' started by Rainy, Oct 2, 2006.

  1. Rainy

    Rainy Guest

    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\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\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.
     
    Rainy, Oct 2, 2006
    #1
    1. Advertising

  2. Rainy

    John Machin Guest

    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\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\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
     
    John Machin, Oct 2, 2006
    #2
    1. Advertising

  3. Rainy

    Rainy Guest

    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\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\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
     
    Rainy, Oct 2, 2006
    #3
  4. "Rainy" <> wrote:

    > 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>
     
    Fredrik Lundh, Oct 2, 2006
    #4
  5. Rainy

    Paul McGuire Guest

    "Fredrik Lundh" <> wrote in message
    news:...
    > "Rainy" <> wrote:
    >
    >> 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
     
    Paul McGuire, Oct 2, 2006
    #5
  6. Rainy

    Rainy Guest

    Paul McGuire wrote:
    > "Fredrik Lundh" <> wrote in message
    > news:...
    > > "Rainy" <> wrote:
    > >
    > >> 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?
     
    Rainy, Oct 2, 2006
    #6
  7. Rainy

    Terry Reedy Guest

    "Rainy" <> wrote in message
    news:...
    >
    > 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
     
    Terry Reedy, Oct 3, 2006
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Deniz Bahar
    Replies:
    2
    Views:
    502
    Andrey Tarasevich
    Mar 9, 2005
  2. rvino
    Replies:
    0
    Views:
    4,696
    rvino
    Aug 14, 2007
  3. Pradeep
    Replies:
    1
    Views:
    325
    Tim Love
    Dec 20, 2007
  4. Le
    Replies:
    0
    Views:
    1,059
  5. bintom
    Replies:
    6
    Views:
    329
    Sprechen sie C++
    Mar 10, 2011
Loading...

Share This Page