The idea of savetxt() (at least for me) is to be a convenience function. After all it is not difficult to write a 2D array to a file. In the use cases I could think of, it would be used for human reading, postprocessing, printing, plotting, etc, rather than rereading by the same program.
In principle, the idea was to somewhat mimic the equivalent function of Python’s Numpy, but we should take into account that they are different languages and the use should be slightly different.
The use of the two versions: savetxt(filename, array) and savetxt(unit, array) were thought to be complementary. I think some of the comments also point in that direction. I would agree to keep the latter version (unit) simple and writing to the “current position” of the file without modifying the position (that would be responsibility of the calling routine). In that case we would have two different signatures:
savetxt(filename, array, .., comments, append)
savetxt(unit, array, .., comments)
I agree that consistency is important and thus the different options should be explicitly stated in the documentation.
Also, I think it could be a good idea to add the options asynchronous|decimal|encoding|round, may be later. For now I would keep it simple, while they could still be used with the unit option.
My mention of the asynchronous|decimal|encoding|round|... arguments of the open statement was intended in the other direction (i.e., NOT to add those, since that’s akin to reinventing the wheel).
And the append argument for the savetxt(filename, ...) version should be ignored if the file is already open, so it’s worth mentioning it in the documentation.
While I agree with the principle, in practice, once a workflow is used, it tends to stay. I’m already aware of many workflows which read and write on such ASCII files simply because the information was already available, or because APIs from other libraries enabled it as the quickest option, etc and so it is kept as an exchange format, even for automated workflows. So I would be very careful about the use of this hypothesis to constrain the design of the API and its internal logic.
I don’t understand. The routine would open and close the file filename. Thus I would expect an (either compilation or runtime) error if we pass a file that is already open.
So, the sensible behavior for savetxt(filename, ...) would be to first inquire if the file is open. If it is, it should then inquire for a unit number, and behave as the savetxt(unit, ...) version, hence my suggestion of ignoring the append argument, to not incur in a possible data loss.
The open statement in fortran does lots of stuff. The obvious is that it opens a file for the first time and connects a unit number to that file. But the open statement can also modify the characteristics of a file that is already open. I gave an example of this above with open(unit,position='append'). That statement operates on a file that is already open and already has a connected unit number and modifies its position. You can also rewind a connected file with the open statement (i.e. instead of using a rewind statement). The items in an open statement that apply to existing connections are called “changeable modes” in the standard. They include such things as blank=, decimal=, delim=, leading_zero=, pad=, round=, and sign=. When combined with the inquire statement, you can query for the current value, temporarily change it to process some i/o operations, and then change it back to its original value.