Nathaniel Smith wrote: > On Mon, Mar 23, 2009 at 11:54 PM, Laurent Gautier > <lgaut...@gmail.com> wrote: >> I have not been using ipython for quite some time, and therefore >> did not think of using its features (I was expecting to have a >> complete implementation to do). > > Yeah, there are probably more interesting ways to spend time than > reimplementing IPython :-). > >> That's definitely something going beyond the use of rnumpy vs >> robjects. It seems possible to have "switch to R" magic that would >> be independent of the high-level interface (you know, today >> robjects and rnumpy, but tomorrow people will come up with >> robjects_like_it_should_be and rnumpy_extra_super_plus ;-) ). > > On the one hand, that'd be nice. On the other... eh. It's easy to get > dizzy worrying about things people might want someday, but it > doesn't accomplish much.
On the other hand rpy2.rinterface and rpy2.robjects were written with those concerns in mind... which let you get from idea to implementation with rnumpy pretty quickly. > When people want it, we can just change the code then. (Or they can, > if they really want it...) > > Really, it's not like there's been a big problem historically with > *too many* people building Python/R interfaces :-). May be because the energy barrier has prevented most from doing so ? > And if anyone invents rnumpy_extra_super_plus, I hope they call it > "rnumpy" (maybe with a version number bump). It may, or may not, work fine (as you may, or may not, approve the proposed modifications ;-) ). > Really, the goal should be to have a single "best of breed" interface > that we can all focus our efforts on, and have a single > recommendation for new users. I'm just not sure how we get there. I have doubts that a one-size-fits-all interface can also be best at everything. For example, in the case of interactive work having high-level bits and pieces easy to customize is probably important, while when someone will look for performances a lower-level layer will be convenient [and why not combine this with a tool like pyrex or Cython]. Things like _munge_py_name_to_r() are very convenient for interactive work, but are too brittle for implementing an IDE for R. ...and about getting to a single interface... well, well... you started by creating your own interface ;-) (which I am seeing as very positive, as that probably means that rpy2.rinterface has reached its goal, and as good/new ideas will come out of this). >>>> I think that the problem listed in the "limitation" can be >>>> worked around by wrapping calls in "withVisible()" (see the tip >>>> in rpy2/demos/radmin.py) >>> Yeah, that's part of a solution, but see my other email. >> It currently is a low-energy way to get it working (see my answer >> to your other email). > > ...I don't see any replies to it (yet)? > >>> My main wishlist from rpy2 right now is: -- that call interface, >>> to fix both the visibility and verboseness problems >> On the radar. >> >>> -- some way for ProcessEvents to get called while blocked in the >>> consoleRead callback (this is tricky!) >> May be less than it seems. The consoleRead callback has a C-level >> wrapper in rpy2/rinterface/rinterface.c, where a flag can be set >> upon entering. ProcessEvents has a wrapper in rinterface.c, and the >> flag previously defined can be checked when entering. (This is does >> protect people hitting directly ProcessEvents through ctypes, but >> well...). > > I'm not sure what you're saying here, I am myself confused about the content 2 days later. > but on further thought, I think the answer is basically just that > there need to be two locks -- one that prevents *all* access to R, > and one that prevents all access to R except ProcessEvents. Most code > takes both, but callbacks can release the latter while processing, > and ProcessEvents only takes the latter. The latter lock is taken > before the former. That would seem to work. >>> -- R->Python calls, so I can provide a magic 'py' object in R >>> mode, that lets one access the Python workspace :-). >> There is semi-dead code from Alexander I keep in the source. From a >> visual inspection, the code looked like it would work... but that >> was before the locking/threading parts. It may require some >> thoughts, but I am hoping to have it for rpy2-2.1.x > > Locking/threading really isn't that big a deal...? My turn to be unsure about your opinion. L. > -- Nathaniel ------------------------------------------------------------------------------ _______________________________________________ rpy-list mailing list rpy-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rpy-list
