Hi, I am replying through the netcdf4-python list where this got out for users to chip in.
Here is what I wrote:
In my experience many of the features are quite similar.
However, netcdf4-python has the advantage of full CDF4 capabilities. Konrads excellent package allows reading a NetCDF4 format in "CLASSIC" format, it also allows writing the CDF3 and CDF3-64 bit files. But it does not allow writing the full NetCDF4 format (I do not know if he has just implemented it, but last time I checked, 2.9.3, he hadn't).
Other than that I see few differences in usage, for my small projects I have created a tiny wrapper to read variables dependent on 3 different netcdf packages. A tiny wrapper can also be made for creating variables even if this is where they differ the most. But once a variable is opened as an instance, retrieving its values through index slices is the same (refrain from using obscure slices).
If the target is to add netcdf4 functionality to the masses through packages, then netcdf4-python is a must as ScientificPython does not add netcdf4 API. However, Konrad does have a point in that ScientificPython is still heavily used and thus many packages might require it, in that regard netcdf4-python is still in its infancy.
So maintaining both could be a vial solution, albeit confusing for the user.
Hope it helps :)
On Thu, 19 Feb 2015 21:33:01 +0100 Konrad Hinsen <
research@khinsen.fastmail.net> wrote:
> Hi everyone,
>
> PICCA Frederic-Emmanuel writes:
> > @Konrad do you think that this netcdf implementation from scientific python could be replace by this
> > netcdf4-python implementation ? Should we get rid of your implentation and use this one instead (to be clear)
>
> The main problem with Python-netCDF interfaces is that no two of them
> have compatible API even for the most basic operations. Whenever some
> Python package depends on netCDF, it depends on one of the various
> Python-netCDF interfaces, and wouldn't work with the other ones.
>
> To make it worse, even if your goal is only to provide a single Python
> interface for new developments, not caring about compatibility, the
> features of the various Python interfaces are sufficiently different
> to make a choice very difficult.
>
> The unique feature of my own netCDF interface, and the reason why
> I keep maintaining it, is the C-level API for other Python modules.
> Each of the other interfaces has such unique features as well.
>
> Konrad.
> --
> ---------------------------------------------------------------------
> Konrad Hinsen
> Centre de Biophysique Moléculaire, CNRS Orléans
> Synchrotron Soleil - Division Expériences
> Saint Aubin - BP 48
> 91192 Gif sur Yvette Cedex, France
> Tel. +33-1 69 35 97 15
> E-Mail: research AT khinsen DOT fastmail DOT net
>
http://dirac.cnrs-orleans.fr/~hinsen/> ORCID:
http://orcid.org/0000-0003-0330-9428> Twitter: @khinsen
> ---------------------------------------------------------------------
>
>