Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #98767 > unrolled thread

Re: Problems using struct pack/unpack in files, and reading them.

Started byIan Kelly <ian.g.kelly@gmail.com>
First post2015-11-13 14:00 -0700
Last post2015-11-13 21:44 +0000
Articles 4 — 3 participants

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Problems using struct pack/unpack in files, and reading them. Ian Kelly <ian.g.kelly@gmail.com> - 2015-11-13 14:00 -0700
    Re: Problems using struct pack/unpack in files, and reading them. Grant Edwards <invalid@invalid.invalid> - 2015-11-13 21:17 +0000
      Re: Problems using struct pack/unpack in files, and reading them. kent nyberg <kent@z-sverige.nu> - 2015-11-13 16:34 -0500
        Re: Problems using struct pack/unpack in files, and reading them. Grant Edwards <invalid@invalid.invalid> - 2015-11-13 21:44 +0000

#98767 — Re: Problems using struct pack/unpack in files, and reading them.

FromIan Kelly <ian.g.kelly@gmail.com>
Date2015-11-13 14:00 -0700
SubjectRe: Problems using struct pack/unpack in files, and reading them.
Message-ID<mailman.306.1447448484.16136.python-list@python.org>
On Fri, Nov 13, 2015 at 1:15 PM, kent nyberg <kent@z-sverige.nu> wrote:
> Even with that, it still gets wrong.
> I also tried .read()[RegisterAX:RegisterAX+4]

When you call read for the second time, are you just reading the same
file again without closing or seeking it in the interim? If that's the
case, then you would get an empty string the second time, which would
explain your error.

Either retain the read data between calls, or call seek(0) before
reading it again.

[toc] | [next] | [standalone]


#98770

FromGrant Edwards <invalid@invalid.invalid>
Date2015-11-13 21:17 +0000
Message-ID<n25k27$m37$1@reader1.panix.com>
In reply to#98767
On 2015-11-13, Ian Kelly <ian.g.kelly@gmail.com> wrote:

> Either retain the read data between calls, or call seek(0) before
> reading it again.

It has always saddened me that Python files don't have a rewind()
method.  On Unix, calling rewind() is the same as calling seek(0), so
it's utterly pointless except as an amusing anachronistic name: it
always made me smile when called rewind() on a file in a filesystem on
a hard-drive.  Interestingly, you can't you can't (and never could)
use rewind() to rewind a tape. You use an ioctl() system call for
that.

-- 
Grant Edwards               grant.b.edwards        Yow! HUGH BEAUMONT died
                                  at               in 1982!!
                              gmail.com            

[toc] | [prev] | [next] | [standalone]


#98772

Fromkent nyberg <kent@z-sverige.nu>
Date2015-11-13 16:34 -0500
Message-ID<mailman.309.1447450493.16136.python-list@python.org>
In reply to#98770
The main problem was that I forgot to do seek(0).  Thanks alot people.

Though, as many times before, the problem was due to misunderstanding of how python works.
I assumed file.read()[xx:yy] was to be understood as,   in the file, read from index xx to place yy.
That is,  [10:20]  was the same as,   read from 10th char to 20th.  Sort of.


Is it true then to say that every .read  of a file, places an index-offset (?) from where the next read starts?
That is, I need to rewind the file, or else the read will start from where the last read stopped?

[toc] | [prev] | [next] | [standalone]


#98773

FromGrant Edwards <invalid@invalid.invalid>
Date2015-11-13 21:44 +0000
Message-ID<n25lkh$egl$1@reader1.panix.com>
In reply to#98772
On 2015-11-13, kent nyberg <kent@z-sverige.nu> wrote:

> Though, as many times before, the problem was due to misunderstanding
> of how python works. I assumed file.read()[xx:yy] was to be
> understood as, in the file, read from index xx to place yy.

Nope.

   First, the 'file.read()' part is evaluated.  That returns the
   entire contents of the file.

   Next, the '[xx:yy]' slice operation is done on the entire contents
   returned in the first step.  The slice operation retuns bytes xx
   through yy-1 (inclusive), and discards the rest of the data.

> Is it true then to say that every .read of a file, places an
> index-offset (?) from where the next read starts?

Yes.  a file object has a current index.  A read() operation always
starts at that index.  When you open the file, that index is 0.  Each
time you read from the file, the index is advanced past the data that
was read.  The seek() method sets that index to whatever you want.

> That is, I need to rewind the file, or else the read will start from
> where the last read stopped?

Exactly.

-- 
Grant Edwards               grant.b.edwards        Yow! Mr and Mrs PED, can I
                                  at               borrow 26.7% of the RAYON
                              gmail.com            TEXTILE production of the
                                                   INDONESIAN archipelago?

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web