[Pytables-users] Re: [ pytables-Bugs-1246097 ] numeric attribute format is painful

[Francesc A. <fa...@ca...>]

A Wednesday 27 July 2005 17:37, Marcus Mendenhall va escriure:
> Please note that this message will contain a full copy of the comment
> thread, including the initial issue submission, for this request,
> not just the latest update.
> Category: None
> Group: None
> Status: Open
> Resolution: None
> Priority: 5
> Submitted By: Marcus Mendenhall (mendenhall)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: numeric attribute format is painful
>
> Initial Comment:
> Somewhere along the line, pytables has changed from writing
> numeric attributes as real HDF5 numbers to what appear to be
> pickled strings.  Although this is very convenient for the python
> community, it makes the tables written by pytables very hard to use
> by other HDF5-reading software, since numbers are not stored
> numerically.
>
> I'm not sure if this is a bug, since I assume the behavior is
> intentional, but it seems sufficiently idiosyncratic that I would like to
> see it reverted (if possible) to writing numbers in native HDF5 format.

Yes, the new behaviour was introduced in PyTables 1.1 and is
completely intentional. This is a consequence of supporting native
HDF5 multidimensional arrays as attributes and the desire to map
directly numarray objects to native attributes. That includes mapping
a numarray scalar (and not a python scalar) to an HDF5 scalar.=20

> Pytables provides a lot of nice extensions to the HDF5 format to
> make it more pythonish, but it seems that the goal should be to only
> use special python constructs when an object is written which really
> cannot be converted to native HDF5.  Then, if the user is careful in
> selecting reasonable base types, the resulting HDF5 files are highly
> portable, which is the goal of HDF5.

If you want to continue writing attributes as native HDF5 scalars,
please, use numarray scalars to do that. For example:

In [3]:f=3Dtables.openFile("/tmp/test.h5","w")
In [5]:import numarray
In [6]:f.root._v_attrs.test1 =3D numarray.array(1)
In [8]:f.root._v_attrs.test2 =3D numarray.array(2, type=3Dnumarray.Float64)
In [9]:f.root._v_attrs.test3 =3D numarray.array(3, type=3Dnumarray.Int8)
In [10]:f.close()

$ h5dump /tmp/test.h5
[...]
   ATTRIBUTE "test1" {
      DATATYPE  H5T_STD_I32LE
      DATASPACE  SCALAR
      DATA {
         1
      }
   }
   ATTRIBUTE "test2" {
      DATATYPE  H5T_IEEE_F64LE
      DATASPACE  SCALAR
      DATA {
         2
      }
   }
   ATTRIBUTE "test3" {
      DATATYPE  H5T_STD_I8LE
      DATASPACE  SCALAR
      DATA {
         3
      }
   }

As you can see, this new method has the advantage of being able to
completely specify the type of the native HDF5 attribute.

Cheers,

=2D-=20
>0,0<   Francesc Altet =A0 =A0 http://www.carabos.com/
V   V   C=E1rabos Coop. V. =A0=A0Enjoy Data
 "-"