Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

readvar() vs putvar()? #169

Open
petershintech opened this issue Dec 25, 2022 · 7 comments
Open

readvar() vs putvar()? #169

petershintech opened this issue Dec 25, 2022 · 7 comments

Comments

@petershintech
Copy link
Contributor

While using NetCDF.jl, I found the package provides readvar() and putvar() for reading and writing a variable respectively. Not sure why the function names were designed in the way, rather than either getvar() and putvar() or readvar() and writevar(). For instance, MATLAB provides getvar() and putvar(), which makes more sense to me. Any reason to introduce the asymmetric function names?

@visr
Copy link
Member

visr commented Dec 28, 2022

Not sure why it was originally called readvar. The C API uses nc_put_var and nc_get_var, to that would be more consistent with the C API, though most packages and Base use read and write more. It's a good observation though I'm not sure it worth changing at this point and break peoples code.

@petershintech
Copy link
Contributor Author

@visr I understand your concern. Then, how about introducing a new function without deprecating an existing one? For instance, to be consistent with other packages, how about creating writevar() function and letting it just call the existing putvar()? Once you have introduced the symmetric interface, I can bet you will see more NetCDF.jl users begin to use writevar() along with readvar(), but I might be wrong.

@petershintech
Copy link
Contributor Author

I just found NetCDF.jl also exports ncgetatt() and ncputatt() so maybe to be consistent with them, introducing getvar() rather than readvar() can be a better choice.

@visr
Copy link
Member

visr commented Dec 28, 2022

I'm personally now only doing very light maintenance on this package, since I'm normally using NCDatasets.jl if I use netCDF files. There was discussion on the future of those packages in Alexander-Barth/NCDatasets.jl#57 but it didn't quite conclude yet.

@petershintech
Copy link
Contributor Author

I dug up NetCDF.jl first because I thought this simpler package is being maintained better than NCDatasets.jl but I might be wrong. When running tests, I could see none of NetCDF.jl tests is broken but some of NCDatasets.jl tests are broken. What is the future of NetCDF.jl? I know NCDatasets.jl provides more elegant interface than NetCDF.jl as netCDF4 is doing for Python users. If NetCDF.jl will be deprecated in the near future, then definitely there is no need to introduce any new functions.

@visr
Copy link
Member

visr commented Dec 28, 2022

I can't really say what the future of this package is beyond the thread I linked. I don't think it will quickly be deprecated though. I'm not sure about broken tests in NCDatasets, on master I see CI is passing. Perhaps good to file an issue if you have local failures.

@petershintech
Copy link
Contributor Author

@visr Thanks for your reply. Then, I will dig up NCDatasets.jl and try to find a way I can contribute something to the package. See you there.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants