[
https://issues.apache.org/jira/browse/ARROW-11120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17261595#comment-17261595
]
Laurent edited comment on ARROW-11120 at 1/8/21, 9:29 PM:
----------------------------------------------------------
[~npr] Disclaimer: I am the author of a large part `rpy2` (and about half of
rpy2-R6, the rest being kindly contributed).
Where to place the line between "need" vs "nice to have" can be debated, but
the idea here is to make the sharing of data without copy between Python and R
(and in the same process) as natural as possible. For the record, rpy2-R6
started as a contribution with the proposition to include it to rpy2. I chose
to keep it out of base rpy2 because of its dependency on an R package not in
R's standard library (R6). This minimizes the maintenance burden (no need for a
new rpy2 release at each API-breaking change in R6). Otherwise it would have
been in `rpy2`.
Otherwise `rpy2` has convenience structures and functions for the so-called S4
system
(https://rpy2.github.io/doc/v3.4.x/html/robjects_oop.html#working-with-r-s-oops),
but the R package to manage a lot of it is in R's standard library.
When it comes to "need" vs "nice to have" a similar argument can be made for
the current code in `sexpextptr.py`. It is not absolutely not needed either and
the few lines of codes there could just be an example in a documentation.
My experience has been that R can be surprising, and that boilerplate code that
helps create code or objects with a more typical behavior in Python (to the
extent R allows it) is quite helpful. I think that the bulk of the rpy2
user-base is from the Data Science world. May be the audience for `pyarrow`
comes more from Software Engineering and minds less about those little
annoyances.
was (Author: lgautier):
[~npr] Disclaimer: I am the author of a large part `rpy2` (and about half of
rpy2-R6, the rest being kindly contributed).
Where to place the line between "need" vs "nice to have" can be debated, but
the idea here is to make the sharing of data without copy between Python and R
(and in the same process) as natural as possible. For the record, rpy2-R6
started as a contribution with the proposition to include it to rpy2. I chose
to keep out of base rpy2 because of its dependency on an R package not in R's
standard library (R6). This minimizes maintenance burden (no need for a new
rpy2 release at each API-breaking change in R6). Otherwise it would have been
in `rpy2`.
Otherwise `rpy2` has convenience structures and functions for the so-called S4
system
(https://rpy2.github.io/doc/v3.4.x/html/robjects_oop.html#working-with-r-s-oops),
but the R package to manage a lot of it is in R's standard library.
Now a similar argument can be made for the current code in `sexpextptr.py`. It
is not absolutely not needed either and the few lines of codes there could just
be an example in a documentation.
My experience has been that R can be surprising, and that boilerplate code that
help create code or objects with more typical behavor in Python (to the extent
R allows it) is quite helpful. I think that the bulk of the rpy2 user-base is
from the Data Science world. May be the audience for `pyarrow` comes more from
Software Engineering and minds less about those little annoyances.
> [Python][R] Prove out plumbing to pass data between Python and R using rpy2
> ---------------------------------------------------------------------------
>
> Key: ARROW-11120
> URL: https://issues.apache.org/jira/browse/ARROW-11120
> Project: Apache Arrow
> Issue Type: Improvement
> Components: Python, R
> Reporter: Wes McKinney
> Priority: Major
>
> Per discussion on the mailing list, we should see what is required (if
> anything) to be able to pass data structures using the C interface between
> Python and R from the perspective of the Python user using rpy2. rpy2 is sort
> of the Python version of reticulate. Unit tests will then validate that it's
> working
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
