Nathaniel Smith wrote: > I'd like to propose that we add a new low-level API to R_tryEval to > rpy2.rinterface. This would be lower-level than the existing > .__call__, .rcall methods, and have the following parts: > * rpy2.rinterface.tryEval (or whatever): a function that takes an > expression rinterface.Sexp, and an environment rinterface.Sexp, calls > R_tryEval, and returns a tuple (result, visibility)
Yes. There was a discussion on this list about it a short while ago. I tried bringing that up to r-devel (since a function R_tryEvalWithVis() would seem to belong to R's API), but did not get much out of it https://stat.ethz.ch/pipermail/r-devel/2009-March/052479.html Someone who feels lucky could try again. One twist I would expect is that R_Visibility is not exported, I think (but I only had a quick look, here again I'd a quiet moment to look at it). > * a way to create LANGSXP's from Python I think that I already made them have the sequence protocol... but I was a little unsure regarding what/how a constructor would look like. Do you have suggestions ? > * a way to create SYMSXP's from Python Looks dangerous at first sight, but you probably have something in mind... so why not try it (and document it as dangerous if this is the case). > * a way to create an environment directly (not via r.environment()) I am not certain of what is your meaning. Do you mean that SexpEnvironment should get a constructor ? In that case, what should it be ? > The advantages would be: > * It would let us replace the 300 lines (!) of tricky and redundant C > code implementing SexpClosure_rcall and Sexp_call (which at a quick > look also appear to have reference counting bugs) with a few lines of > Python. Some code cleaning is expected to come with 2.1.x, as well as API-breaking changes. (2.0.x is result of some thought and learning process... it is certainly easier to how it could be done and where code similarities are, once it is done and working). Redundancy is close to inevitable, as _rcall grew out of some limitations in _call (the said limitations having been found through use), and users of the early 2.0.x had to expect some stability on such core functionalities). Still, and beside the fact that as thing stabilize the code similarities can probably be handled better at the source level, _call and _rcall are somewhat different in their behaviour (the rpy2 doc outlines that), and are yet different from what you would like to have for rnumpy. [note: telling *where* you suspect a reference counting leak is probably more helpful than just telling that you saw one ;-) ] > * Having uniform access to visibility information would let us fix one > of the most annoying rnumpy bugs. (withVisible is ok for general code, > but it doesn't help for calls like r.plot(...).) withVisible has a number of annoying side effects. The annoying part is that there appear to be something missing in the C-level API for R (and I'd see saner to propagate that back to R rather than struggling with our own construct... if we can.). I was hoping to find the time propose a patch to R-devel... > * More flexibility in how we pass expressions to R for evaluation. In > rnumpy, I would do calls like: > env = new_env(base=globalEnv) > env["<Python-wrapped function>"] = fn > env["<Python-wrapped argument 1>"] = arg1 > ... > > (result, visibility) = tryEval([symbol("<Python-wrapped function>"), > symbol("<Python wrapped argument 1>"]), ..], env) > Then those names would be what showed up in tracebacks and plot > titles. This may seem trivial, but it's by *far* the most annoying > problem I run into when using rnumpy myself, and there doesn't seem to > be any other solution. I'd say that it is *currently* possible, and with few lines of Python. import rpy2.robjects as ro def rparse(x): res = ro.baseNameSpaceEnv["parse"](text = x) return res rlocal = ro.r['local'] def my_eval(fun_name, arg_names, env): res = rlocal(rparse('withVisible(%s(%s))' %(fun_name, ', '.join(arg_names))), env) return res ro.globalEnv['x'] = ro.IntVector([1,2,3]) # I am not certain of why you want that ro.globalEnv['sum'] = ro.r['sum'] print(my_eval('sum', ('x', ), ro.globalEnv)) > Does that sound sensible? I can write the code, but I wanted to throw > the idea out there to make sure it'd be welcome and I hadn't forgotten > anything, first. I might have overlooked something. Don't hesitate following up. L. > -- Nathaniel > > ------------------------------------------------------------------------------ > Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are > powering Web 2.0 with engaging, cross-platform capabilities. Quickly and > easily build your RIAs with Flex Builder, the Eclipse(TM)based development > software that enables intelligent coding and step-through debugging. > Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com > _______________________________________________ > rpy-list mailing list > rpy-list@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/rpy-list ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ rpy-list mailing list rpy-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rpy-list
