[Numpy-discussion] problem calling SD.SDim.setname in pyhdf
Mon Sep 29 18:07:13 CDT 2008
On Mon, Sep 29, 2008 at 17:39, Catherine Moroney
> I recently upgraded pyhdf from 0.7-3 to 0.8-2, and have noticed some
> problems with the SD.SDim interface.
> Specifically, the short test code attached works fine with version 0.7-3
> and fails with version 0.8-2 when it's trying to assign a name
> to the dimension.
> I get the following error (below). Does anybody else have similar
> while trying to attach a name to an SDim object in the most recent
> of pyhdf?
> I'm running on a Linux box, python version 2.5.
> etting Dimension: Dimension0
> Traceback (most recent call last):
> File "./Test_pyhdf.py", line 35, in <module>
> File "./Test_pyhdf.py", line 27, in main
> File "/usr/lib64/python2.5/site-packages/pyhdf/SD.py", line 2856,
> in setname
> _checkErr('setname', status, 'cannot execute')
> File "/usr/lib64/python2.5/site-packages/pyhdf/error.py", line 24,
> in _checkErr
> raise HDF4Error, str
> pyhdf.error.HDF4Error: ('s', 'e', 't', 'n', 'a', 'm', 'e', ' ', ':',
> ' ', 'c', 'a', 'n', 'n', 'o', 't', ' ', 'e', 'x', 'e', 'c', 'u', 't',
We have noticed the same thing on 64-bit Linux platforms. We are
currently tracking this bug here:
Please report pyhdf problems to the enthought-dev mailing list, rather
than here (as I am probably the responsible party).
Unfortunately, I don't know what's wrong at the moment.
"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
-- Umberto Eco
More information about the Numpy-discussion