Actually my vision with pyhdf5io is to have hdf5 to replace numpy's own binary file format (.npy, npz). Pyhdf5io (or an incarnation of it) should be the standard (binary) way to store data in scipy/numpy. A bold statement, I know, but I think that it would be an improvement, especially for those users how are replacing Matlab with sicpy/numpy. I don't know if this vision of mine is possible to realize, or even something that is shared by anyone else in the community. So list what are your thoughts? Are there some people out there, who like the idea and want to cooperate in realizing it? /Albert On Sat, May 23, 2009 at 13:47, David Warde-Farley <dwf@cs.toronto.edu> wrote:
On 23-May-09, at 5:36 AM, Albert Thuswaldner wrote:
So i guess in the long term i have to also add pickling support. In the short term i will add warnings for the data types that are not supported.
In order to ensure optimal division of labour, I'd suggest simply basing your pickling support on hdf5pickle, and including it as an optional dependency, that you detect at runtime (just put the import in a try block and catch the ImportError). If you have hdf5pickle installed, pyhdf5io will pickle any objects you try to use save() with, etc. Otherwise it will just work the way it does now.
I think that satisfies the goals of your project as being a thin wrapper that provides a simple interface, rather than reinventing the wheel by re-implementing hdf5 pickling. It also means that there aren't two, maybe-incompatible ways to pickle an object in HDF5 -- just one (even if you write your implementation to be compatible with Pauli's, there's opportunity for the codebases to diverge over time).
David _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion