Make %R / %%R and default rpy2 import/export semantics the same

Issue #179 new
Dav Clark created an issue

This is an old issue that was raised some time ago here. I propose that now is the time to either change these semantics to be the same, or agree that they should remain different (as per Thomas' arguments)

Comments (8)

  1. Dav Clark reporter

    Note - the numpy dependency introduced in ipython.rmagic can be replaced by unlist on the R side in any case.

  2. Laurent Gautier

    Where are we with one ? The GitHub issue seems to be based on the assumption that Python list are / should be homogeneous in type.

    While the Python documentation refers to lists as /generally homogenous/ while tuples are /generally heterogeneous, it also specifies that the degree of homology varies (so every element in a list is aobjectanyways, making the list homogeneous in any case under this definition). There is otherwise nothing to indicate that this is considered good, or bad, practice. Python'sarray.array` are made for homogeneous vectors otherwise.

    There are enough quirks with interfacing R without the need to add guesswork about what a user mean. I have a hard time believing that creating homogeneous vector is deemed too hard a task for users (and the options to do so are many: rpy2's own IntVector, FloatVector, etc..., or array.array, numpy... anything exporting the Python buffer interface).

    Currently, the only change I might consider is to remove the conversion of lists (that is rpy2 return an error whenever a plain Python list (or tuple) is entering the conversion layer - note: this change in behavior could be experimented by the ipython submodule by implementing a custom conversion).

  3. Dav Clark reporter

    I chatted with @takluyver about this a bit. I think he has raised some good points about convenience (e.g., it's useful to be able to pass python lists into R functions like plot()). I can dig up the old thread if you'd like.

    But, on some level I also don't like the forced auto-conversion.

    My feeling is that it would be nice to have an option here. I haven't worked out the details, but for example, you could imagine:

    %load_ext rpy2.ipthon

    Here, %Rmagic would enable convenience conversions. This could happen via a call to something in the robjects namespace, or it could live in the ipython code. If you don't call %Rmagic, you get pure assignment with rpy2's default semantics.

  4. Laurent Gautier

    With revision d0b42a0bee6c there is an helper function that should make adding the conversion of Python lists (either the default in rmagic or a user-specific customization) easy:

    %load_ext rpy2.ipython
    from rpy2.ipython import rmagic
    from rpy2.robjects import sequence_to_vector
    # register conversion for lists
    rmagic.ipython2ri.register(list, sequence_to_vector)
    # register conversion for tuples
    rmagic.ipython2ri.register(tuple, sequence_to_vector)
  5. Laurent Gautier

    I just fixed a likely bug (revision 39fe6eb21779 , in branch default) where a call to conversion was missing when using the parse+eval wrapped by R.__call__(). If one of the two ways to call R was using this and the other did not, this could explain the difference of behavior.

  6. Dav Clark reporter

    I have long been meaning to implement the somewhat internal logic used in simplify2array (a helper function for sapply and friends). I think the right approach is likely to stick with minimal computation (so adding simplify2array would be a net negative). But this might be a good first use of the custom converter. I comment here mostly so I don't have to look up that function again.

  7. Log in to comment