Open JonasIsensee opened 3 years ago
I like this idea, I think we can deprecate the single-positional-argument method in favor of a manually written one data->save(f, data)
. But this takes time to proceed and I don't know how others feel about it.
In the meantime, adding a non-exported symbol kwsave
seems okay to me. When the deprecation finishes, we can deprecate kwsave
in favor of save
.
I think we can deprecate the single-positional-argument method
This is very heavily used in queryverse. The entire file IO story revolves around this pattern, so I would be very, very opposed to this :)
I recognize it's useful functionality, and we should keep it. But it's undocumented behavior of FileIO.save
and it doesn't really fit with any Julia standard elsewhere (neither the "omit an IO object and fill in a default" nor the "first argument is a function which you can define via a do
block"). I think we could call this something new, maybe writer
, to hint that it returns a function that writes data? Or might savestreaming
already solve that problem in a more conventional way?
I've added a new syntax to JLD2 and I'm wondering if this could be made compatible with FileIO.
Current example using
FileIO
:This is clearly very verbose, particularly when variable names are long. However, this could be made much cleaner if we use keyword argument syntax instead
What's great about this, is that we use standard julia syntax and let the parser do the work of extracting variable names. Until now this was only possible using the
@save
and@load
macros from e.g. BSON, JLD, or JLD2 but these macros introduce odd (and limited) syntax and keep being misunderstood by newcomers.I'm aware that kwarg stuff is typically not type-stable but this is rarely important when IO is involved.
The problem: There already is a single-positional-argument method for
FileIO.save
that returns an anonymous function to be used with pipes.What do you think? Is this interface idea useful enough to add it to
FileIO
in some way?