So I forgot about python-netcdf and pupynere.
That adds up to 3 APIs from 5 packages I know of:
* pyCDF (circa 2007):
* Scientific.IO.NetCDF : from python-netcdf or pupynere
* scipy.io.netcdf : from scipy, or python-netcdf4
python-netcdf appears to work with netcdf4 these days, or rather, it uses netcdf4 libraries
and so will _read_ these files, but doesn't give an API to manage them (eg. compression facilities, parallelism, etc)
to my knowledge.
The point is that we _don't_ want 2 APIs and 5 packages, but rather to converge on one.
A package that I'm working on passes back a CDF object (originally from pyCDF, planned now
to be a netcdf_file object from scipy.io.netcdf) to the user; ie. it assumes the underlying netcdf package
I'm using is pyCDF. We're in danger of having code that uses multiple netcdf libraries.
NetCDF is morphing from a simple file format to being a way of handling large scientific data (especially using
HDF5 underneath, as in netcdf4). The files can easily be 10-100 GB in size, and with netcdf using the opendap library
underneath to read the contents as-needed over a network, its important to be able to pass netcdf objects around
without reading the contents of the underlying file unless necessary: ie abstractions that involve hiding netcdf
by reading in the file into memory are not an option.
Is it possible to standardize on one python netcdf implementation, based on the latest netcdf4 libraries?
[note: I'm having some difficulties posting to debian lists at the moment. If this mail does not appear
on debian-science, can you please repost on my behalf? thanks]
On 2012-04-18 20:56, Arnaldo Russo wrote:
-- Alastair McKinstry , <firstname.lastname@example.org> , <email@example.com> http://blog.sceal.ie Anyone who believes exponential growth can go on forever in a finite world is either a madman or an economist - Kenneth Boulter, Economist.