Extracting a short using struct - won't print.

Discussion in 'Python' started by Graham Nicholls, Aug 7, 2003.

  1. Thanks to Richard and Alex, I'm doing this:

    seg_stru=">BHH"
    seg_data=self.fhand.read(struct.calcsize(seg_stru))
    data=struct.unpack(seg_stru,seg_data)
    x=seg_data[1]
    y=seg_data[2]
    if debug:
    print ("DEBUG: Image [%s] is [%d] by [%d] pixels" % (self.fname,x,y))

    Expecting to extract a filler byte (ignored), then a big-endian short (a
    python integer) , then another of the same. When I try to print, I get
    this:

    File "./pdf_merge", line 426, in getsize
    print ("DEBUG: Image [%s] is [%d] by [%d] pixels" % (self.fname,x,y))
    TypeError: int argument required

    What am I missing - its probably something simple - earlier I spent half an
    hour wondering why I was getting a message that "img_file has no object
    getsize()" from x,y=img.getsize(). It turned out to be because I had got
    def getsize: indented one indent too far in the class definition. Aaargh!

    Python is 2.3b1.

    Thanks
    --
    Graham Nicholls
    Rock Computer Consultancy
    Graham Nicholls, Aug 7, 2003
    #1
    1. Advertising

  2. Peter Hansen wrote:

    > Graham Nicholls wrote:
    >>
    >> Thanks to Richard and Alex, I'm doing this:
    >>
    >> seg_stru=">BHH"
    >> seg_data=self.fhand.read(struct.calcsize(seg_stru))
    >> data=struct.unpack(seg_stru,seg_data)
    >> x=seg_data[1]
    >> y=seg_data[2]

    >
    > Why are you unpacking the struct if you aren't going to use the
    > unpacked data?


    Err, I'm trying to extract two shorts - the x and y size in pixels of an
    image, which I'll use to scale it to fit another pair of parameters. What
    makes you think I'm not using the data? Am I not - I thought I was!

    I realise that ">BHH" above ouhjt really to be "xHH" but aside from that, I
    don't understand your point - theres more code after the debug in the rel
    app - returning x and y.

    >
    >> if debug:
    >> print ("DEBUG: Image [%s] is [%d] by [%d] pixels" %
    >> (self.fname,x,y))

    >
    > Best way to troubleshoot this kind of thing, in my experience,
    > is to insert "import pdb; pdb.set_trace()" into the code just
    > above the failing line, then use the debugger to inspect the
    > values directly just before they are used. (You need to execute
    > the "r" or "return" command immediately after the debugger is
    > entered... the rest is pretty straightforward to learn.)
    >

    I'll give that a go, thanks
    > -Peter


    --
    Graham Nicholls
    Rock Computer Consultancy
    Graham Nicholls, Aug 7, 2003
    #2
    1. Advertising

  3. "Graham Nicholls" <> wrote in message
    news:3f32779d$0$10780$...

    > >> seg_stru=">BHH"
    > >> seg_data=self.fhand.read(struct.calcsize(seg_stru))
    > >> data=struct.unpack(seg_stru,seg_data)
    > >> x=seg_data[1]
    > >> y=seg_data[2]

    > >
    > > Why are you unpacking the struct if you aren't going to use the
    > > unpacked data?

    >
    > Err, I'm trying to extract two shorts - the x and y size in pixels of an
    > image, which I'll use to scale it to fit another pair of parameters. What
    > makes you think I'm not using the data? Am I not - I thought I was!


    You aren't using the returned value from struct.unpack() anywhere.
    You need something like x, y = struct.unpack(seg_stru,seg_data)
    Richard Brodie, Aug 7, 2003
    #3
  4. Graham Nicholls wrote:

    > Peter Hansen wrote:
    >
    >> Graham Nicholls wrote:
    >>>
    >>> Thanks to Richard and Alex, I'm doing this:
    >>>
    >>> seg_stru=">BHH"
    >>> seg_data=self.fhand.read(struct.calcsize(seg_stru))
    >>> data=struct.unpack(seg_stru,seg_data)
    >>> x=seg_data[1]
    >>> y=seg_data[2]

    >>
    >> Why are you unpacking the struct if you aren't going to use the
    >> unpacked data?

    >
    > Err, I'm trying to extract two shorts - the x and y size in pixels of an
    > image, which I'll use to scale it to fit another pair of parameters. What
    > makes you think I'm not using the data? Am I not - I thought I was!
    >
    > I realise that ">BHH" above ouhjt really to be "xHH" but aside from that,
    > I don't understand your point - theres more code after the debug in the
    > rel app - returning x and y.
    >
    >>
    >>> if debug:
    >>> print ("DEBUG: Image [%s] is [%d] by [%d] pixels" %
    >>> (self.fname,x,y))

    >>
    >> Best way to troubleshoot this kind of thing, in my experience,
    >> is to insert "import pdb; pdb.set_trace()" into the code just
    >> above the failing line, then use the debugger to inspect the
    >> values directly just before they are used. (You need to execute
    >> the "r" or "return" command immediately after the debugger is
    >> entered... the rest is pretty straightforward to learn.)
    >>

    > I'll give that a go, thanks
    >> -Peter

    >

    OK, the code now looks like this:



    seg_stru=">xHH"
    seg_data=self.fhand.read(struct.calcsize(seg_stru))
    data=struct.unpack(seg_stru,seg_data)

    x=seg_data[1]
    y=seg_data[2]
    import pdb ; pdb.set_trace()
    if debug:
    print ("DEBUG: Image [%s] is [%d] by [%d] pixels" % (self.fname,x,y))
    return(x,y)

    When I run it, I get this:

    EBUG: Scaling image file hb.jpg to fit 100 100
    DEBUG: Searching hb.jpg for dimensions
    DEBUG: found header type e0
    DEBUG: found header type db
    DEBUG: found header type db
    DEBUG: found header type c0
    --Return--
    > /usr/local/lib/python2.3/pdb.py(972)set_trace()->None

    -> Pdb().set_trace()
    (Pdb)
    (Pdb) r
    > /home/graham/work/hsb/pdflive/pdf_merge(427)getsize()

    -> if debug:
    (Pdb) print x

    (Pdb) print y
    m
    (Pdb)

    Which _seems_ to indicate that unpack is not unpacking the shorts as shorts,
    but as chars. Is this right?

    Thanks
    Graham
    --
    Graham Nicholls
    Rock Computer Consultancy
    Graham Nicholls, Aug 7, 2003
    #4
  5. Graham Nicholls wrote:

    > Richard Brodie wrote:
    >
    >>

    ....snipped

    >
    > I told you it'd be something stupid!
    > I mean
    > x=data[1]
    > y=data[2]
    > don't I!
    > Thanks!!!!
    > Graham


    Which, of course works - one of the annoying things about learning a
    language is that you tend to assume its something more complex than it
    really is when you get an error. I'd see that in 2 seconds flat in a c
    program , of course, but then the compiler would help..

    BTW How does one test python programs - because its interpreted, it often
    won't run bits of code till unexpected circumstances, so a syntax error can
    be hidden until runtime?

    Graham
    --
    Graham Nicholls
    Rock Computer Consultancy
    Graham Nicholls, Aug 7, 2003
    #5
  6. Peter Hansen wrote:

    > Graham Nicholls wrote:
    >>
    >>
    >> don't I!

    >
    > Yes, you do! :) Sorry for not being more obvious about the answer,
    > and I thought you might figure it out yourself by using the "import pdb"
    > trick I showed. "Teach a man to fish" and all that. <grin>


    Too tired to fish, but thanks, I suspect will be a useful technique.
    Graham
    >
    > -Peter


    --
    Graham Nicholls
    Rock Computer Consultancy
    Graham Nicholls, Aug 7, 2003
    #6
    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. Chris Fogelklou
    Replies:
    36
    Views:
    1,345
    Chris Fogelklou
    Apr 20, 2004
  2. David Geering

    longs, long longs, short short long ints . . . huh?!

    David Geering, Jan 8, 2007, in forum: C Programming
    Replies:
    15
    Views:
    544
    Keith Thompson
    Jan 11, 2007
  3. Replies:
    4
    Views:
    798
    Kaz Kylheku
    Oct 17, 2006
  4. Ioannis Vranos

    unsigned short, short literals

    Ioannis Vranos, Mar 4, 2008, in forum: C Programming
    Replies:
    5
    Views:
    657
    Eric Sosman
    Mar 5, 2008
  5. Andre
    Replies:
    5
    Views:
    517
    Keith Thompson
    Jul 17, 2012
Loading...

Share This Page