Repository navigation
fwrite() should (possibly invisibly) return the file path #5706
Description
Activity
why the file path as opposed to
x?the latter behavior would be more like
print()where a function used for side effects returns it's main argument (https://design.tidyverse.org/out-invisible.html)I guess because then you can work with the results of the write in the pipeline. It would be analogous to
fs::file_create()in that page. Also, you already have easy access toxin your environment, while the path to the file might not be available since it might be created on based on data. For instance:DT[, fwrite(.SD, group), by = group]
Will create a bunch of files, but you don't have access to them (the result is an empty data.table). If
fwrite()returned the created file you could dofiles <- DT[, fwrite(.SD, group), by = group]
and then use
filesin your code easily.It would be analogous to
fs::file_create()Not really, because the "main argument" of
file_create()is the file path. The main argument forfwrite()isx.you already have easy access to x in your environment
Not necessarily, e.g.
fwrite(DT[...], file)where now the output can be any table.Your code can be done currently like:
files <- DT[, fwrite(.SD, .BY$group), by = group]$group
More generally, I think it's just a difference between code like:
DT[, by = group, { ... fwrite(.SD, file, ...) .SD }]
and
DT[, by = group, { ... fwrite(.SD, file, ...) file }]
So I'm still not sure why to prioritize one over the other.
One way to approach this empirically would be to find out which object is used more:
https://github.com/search?q=lang%3AR+%22fwrite%28%22+%22.SD%22+%22%7B%22&type=code
Oh, sorry, I meant
fs:file_copy(from, to), which returnstoinstead offrom.One issue with your examples is that you only grab the file name and not the full path.
For
fwrite(DT[...], file), you could always dofwrite(saved_data <- DT[...], file). I'd argue that if you're computing something inside the call tofwrite()then you probably don't care about the output in the rest of your code, otherwise you would save it to a variable and then save it. A more realistic example could be to save intermediate steps in a pipeline like:DT2 <- DT |> _[...] |> fwrite("file.csv") |> _[...]
But the
%T>%pipe might be more useful for that, as you are not relying on the return value of the intermediate function.- changed the title
[-]`fwrite()` should (possibly invidibly) return the file path [/-][+]`fwrite()` should (possibly invisibly) return the file path [/+]on Nov 3, 2023 @eliocamp I think that adding a write step between several modification steps would affect code readability.
It will take more time to a new user to understand when we are saving the data in the script
I agree. That's why I think that
fwrite()should return the path to the created file. So the next step after writing would be to do stuff with the file, which is relatively clear and straightforward.Reacted by Jan Gorecki and Angel Esteban FelizGot it.
It will prevent me from writing a for loop to achieve that task. I wouldn't have written the next code as it is really clever.
files <- DT[, fwrite(.SD, .BY$group), by = group]$groupIt can become much harder if we want to save the files in a folder, so returning the file's path seems to be a good a idea.
files <- DT[, fwrite(.SD, paste0("data/", .BY$group, ".csv")), by = group]Hi i want to work on this issue , @MichaelChirico I wanna know what you think should be returned
xorfile path, and can you give me some idea about stuff need to be done for this issue :)AFAIU there is no decision made yet what should be returned by
fwrite. First step could be to scan popular packages and see what they do or what base does, e.g. check out the writing to disk methods forutils::write.table,vroom,fst, etc.Reacted by Nitish JhaI would say if they return NULL then it is not very useful follow them. TRUE is already better result then NULL...
I would say if they return NULL then it is not very useful follow them. TRUE is already better result then NULL...
what do you think should be returned?
File name or path, depends what was provided
Reacted by Nitish Jha
Now
fwrite()returnsinvisible(), but I think it might be more useful if it returned the path to the created file. It's a trivial change and I don't think it would create issues with backward compatibility, since it's probably not likely that any code relies onfwrite()not returning anything (although a similar change toggsave()did break a few scripts 🤣).