csgillespie commented on issue #38456:
URL: https://github.com/apache/arrow/issues/38456#issuecomment-1781487093
Naming things is hard!
So, I've tried to think about the "right thing to do" from the start (purely
personal POV).
* It doesn't bother me that there's a namespace issue with {readr}. Having
the same name would benefit me, as I could switch back ends more easily.It also
indicates that `read_csv()` are (sort of) interchangeable
* The same applies to `write` functions. The fact there are `_file`,
`_csv_arrow`, `_feather`, etc. is a little odd
* I also think that people should namespace functions for reading/writing
data. But that's just me :)
* Going back to the first point, if the function name was the same, I could
more easily see the benefit of {arrow}.
So, it would make sense to step back and consider renaming some of the
functions. The easiest way could be to create aliases, print a message about
the new name, and then deprecate at some point in the distant future.
---
Ideally, the argument should be `as_tibble`, but changing it now is probably
annoying.
---
> I've been thinking it might be worth us spelling out the different
functions more directly in an article - what do you think?
The docs are excellent. I'm just being annoying. I don't think you need an
article.
> I'd be keen to hear more about what's made you think about this - your own
usage, comments from clients of yours who are using arrow, etc.
So, I'm writing some blog posts on this stuff. So I understand what's going
on. So things like
> as_data_frame: Should the function return a tibble (default) or an Arrow
Table?
Automatically made me think, "Is {arrow} being sneaky and loading {tibble}"?
The answer is no, but it's the way I learn.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
