Need to convert an arbitrary byte-pair to an int.

[Graham Nicholls]

Hi,
I'm trying to size a jpeg file. The file size is held in a short (2 byte
integer) at a certain offset. Once I've found these two bytes (they're in
MSB,LSB order), I need to convert them to an integer - now I know that in C
I'd just cast a pointer to the offset to a short, and that python doesn't
cast, so how can I extract the value from a stream of bytes. I've looked
at python.org/Doc/current (I'm using 2.3b1), but can't find anything
obvious.



Thanks

 

[Alex Martelli]

I'm trying to size a jpeg file. The file size is held in a short (2 byte
integer) at a certain offset. Once I've found these two bytes (they're in
MSB,LSB order), I need to convert them to an integer - now I know that in
C I'd just cast a pointer to the offset to a short, and that python
doesn't
cast, so how can I extract the value from a stream of bytes. I've looked
at python.org/Doc/current (I'm using 2.3b1), but can't find anything
obvious.

I see you've already been pointed to a 3rd party package that's useful for
handling images, but just in case you to need to solve in the future the
actual problem you pose in the subject, one elementary way might be:

thefile = open('whatever', 'rb')
thefile.seek(theoffset)
msb = thefile.read(1)
lsb = thefile.read(1)
theint = ord(lsb) + ord(msb) * 256

The struct module, which I see has also been pointed out to you already,
would let you compact the last three statements into one. So, in this
specific case, would the array module. Both struct and array are part
of the standard Python library and often come in handy for occasional
needs of low-level access, such as this.


Alex

 

[Graham Nicholls]

<posted & mailed>

I see you've already been pointed to a 3rd party package that's useful for
handling images, but just in case you to need to solve in the future the
actual problem you pose in the subject, one elementary way might be:

thefile = open('whatever', 'rb')
thefile.seek(theoffset)
msb = thefile.read(1)
lsb = thefile.read(1)

theint = ord(lsb) + ord(msb) * 256

^^^^^^^^^^^^^^^^^
This is what I was trying to do, only getting confused with abs, atoi and
various other invocations which either dont exist or don't do what I wanted
them to.

The struct module, which I see has also been pointed out to you already,
would let you compact the last three statements into one.

And IMO is rather more elegant.

So, in this
specific case, would the array module. Both struct and array are part
of the standard Python library and often come in handy for occasional
needs of low-level access, such as this.

Trouble is, you don't know what you don't know, and my python library
reference is at home, and I'm onsite.

Alex

Alex (and Richard),

Thanks for that. The struct module was just what I was after. (I cancelled
my reply which implied that the 3rd party module was the answer, when in
fact, I'd meant to say that using struct is _exactly_ what I want).

Jpeg files have a header, then a series of segments, each of which contains
within it the segment size, so using a struct (just like in c, really) is a
great way to read the segment type and size.

BTW, I posted a month or so back wondering about the merits of Python, which
I already much prefer to perl, but I've sort of simultaneously been
learning Ruby & Python. Not sure which I prefer, yet, but I think that a
reasonable knowledge of both, perhaps with in depth understanding of one of
them, would be useful. Python seems to have more modules, and I do like
lots of things about it, but Ruby _seems_ cleaner, somehow. Its an
interesting exercise, trying to learn both (whilst being quite busy).

Thanks again.

 

[Alex Martelli]

Graham Nicholls wrote:
...

Trouble is, you don't know what you don't know, and my python library
reference is at home, and I'm onsite.

The python library reference is also online -- see for example
http://www.python.org/doc/current/lib/lib.html -- and if one happens
to prefer "Python in a Nutshell", why, THAT one is too (on O'Reilly's
"safari" service -- however, after some weeks' worth of free trial, if
you want to continue accessing "safari" you'd have to subscribe to it).

them, would be useful. Python seems to have more modules, and I do like
lots of things about it, but Ruby _seems_ cleaner, somehow. Its an

Interesting. I'm also trying to learn Ruby in my copious spare time
and don't really see that "clean-ness" (all of those 'end' terminators
of block, how are they "cleaner" than the lack thereof in Python? How
is it "cleaner" to have regular expressions deeply mixed in the
innards of the language rather than cleanly separated into their own
library modules? Etc, etc). I _do_ see that Ruby provides more scope
for tinkering, because it lets me play with the way operations on
built-in types work -- so if I want e.g. 2+2 to evaluate to 5, I can
(or more seriously, I can perform presumably-useful modifications to
other special methods of built-in types). But I think the same key
difference that makes Ruby better for tinkering -- the total fluidity
and dinamicity of just about everything, with no "fixed posts" for
the behavior of built-in types -- may make it less suitable for the
programming of large, multi-developers, indeed multi-team application
programs. Python is highly dynamic but draws the line at modifying
behavior of built-in types; Ruby draws no such line, and thus it is
even more dynamic. To me, on the basis of my understanding of both
languages so far, THAT is the one _crucial_ language difference (the
_libraries_ may differ more broadly, but that's secondary and even
easily remedied -- the languages' philosophy regarding such dynamic
possibilities, however, are far less likely to ever change).

Other more specific tradeoffs, such as Ruby's _mutable_ strings (which
I mostly dislike, but may sometimes help performance) or the very
different style of iterators in the two languages (in Ruby you pass a
code block into the iterator, while in Python you get values out of
the iterator one by one -- so, for example, stepping over more than
one iterator in a controlled way is far easier in Python, while
other tasks are easier in Ruby -- I think, overall, the power of
the very iterators in the two languages may be very similar, with a
tiny edge to Ruby, while the simplicity and syntax cleanliness of
coding is IMHO a substantial edge to Python) -- all of these can be
discussed point by point, of course.


Still, I agree that both languages are quite good. If Python did
not exist, I believe I would most probably be using Ruby, myself.


Alex