Hey hey,

thank you for the initiative!
Originally, we decided against implementing import and export support, primarily because was that Python has many great tools supporting import and export. Those tools can effectively be used as pre- and postprocessing options for GSTools.
However, at least supporting rudimentary import and export methods can be very convenient. That said, everything else beyond rudimentary support would either amount in a lot of work or large dependencies like Polars or Pandas.
Additionally, CSV is a format which shouldn't receive even more standalone support than it has already, as summarized poignantly here. So, how about this compromise: We support export functionality through the main Numpy export functions, like

• savetxt
• save
• savez
• savez_compressed

I think this should be easily doable, by providing another argument with which you can choose your export function/ format. I think it would even be okay for me, if CSV stays the default format.
What do you think?

Friends don't let friends export to CSV

😂

This implementation is just numpy.savetxt with a header-line for the names and a "," to separate the values (hence CSV is quite a good term here).
I think it is so straight forward, that I don't mind having it and people actually asked for it: #366

For further IO stuff I would like to be able to pickle and unpickle our objects and/or use (safer) serialization approaches like json.

Should we rename it to savetxt? I just wanted to be consistent with vtk_export.

Yes, I had a look at your implementation. But from a quick check, it seems that savetxt, save, ... all look very similar, they also take variable names, ...
You can even pickle your variables ;-)

I like the name of the function and I think you should keep csv_export.

Why would you want to specifically support json export? I don't think that json is a very fitting format for GSTools and would much more prefer other formats.

But json for example to store CovModel configuration? I think this would be really cool.

I think all the others export routines are more meant to be used for storing and loading again, since they are not human readable file formats.
I don't want to implement a "load-from-file" method at the moment and as you said, the users could use the Python eco-system to create files as they want.

I think all the others export routines are more meant to be used for storing and loading again, since they are not human readable file formats. I don't want to implement a "load-from-file" method at the moment and as you said, the users could use the Python eco-system to create files as they want.

Exactly, the npy- and npz-files are binary and Numpy understands their content, making the reading much easier than CSV files. I actually use an npz-file for one of the plurigaussian examples

So, I don't really get your argument against supporting Numpy's other save functions.

But json for example to store CovModel configuration? I think this would be really cool.

We should probably shift this discussion to another time ;-)