Nathaniel Smith wrote: > On Sun, Feb 8, 2009 at 2:22 AM, Laurent Gautier <lgaut...@gmail.com> wrote: >> In the case of extracting elements from a matrix, there is a way >> (working in R, as well as in rpy2): >> >> m[2, TRUE] # Note the TRUE ! >> [1] 2 4 > > Ah, cute trick, thanks. > >> I'd be more keen on defining the missing magic, as well as NULL and the NA_* >> group as user-immutable objects in a module (rather than functions). >> I started looked at how this could happen with the NA_* group, but got too >> busy on the day job otherwise and had to interrupt half-way through. >> One point of concern is that that those variables are not valid until R is >> initialized. This is rather easy to solve when considering the use of >> functions such as getNA_REAL() or getMissingArg(), but not when considering >> non-callable objects in a module. > > Well, I agree that attributes look nicer, but like you say, the way I > did it has the advantage of actually working :-). > > One could just add the line > MISSING = rinterface.getMissingArgSexp() > to robjects/__init__.py and have the nice API that way. (It wouldn't > be immutable in the same way, but that's true of basically everything > in the entire Python world, including __builtins__, so that doesn't > seem too bad.)
Yes. I would actually put at the rinterface/__init__.py level (still at the rinterface level, but this would cut down on C-level development time). > Alternatively, why not just initialize R unconditionally at rinterface > import time? Yes, rpy-1.x has been doing that. I moved to an explicit initialization rather early when I started with ryp2 because: - I found that in theory the Embedded R could be stopped (then why not started again) - well, the "in theory" caught me a little later. - I wanted an easy way/elegant way to initialize parameters. http://rpy.sourceforge.net/rpy2/doc/html/rinterface.html#initialization With an implicit initialization, I found all solutions I have coming up with not very elegant (and error-prone)... unless I'd go for a separate module for custom initialization purposes (might be the turn I take for rpy2-2.1). You'll note that the higher-level interface in rpy2.robjects does an (hopefully sensible) initialization (unless an explicit initialization is done earlier). > In practice everyone does this anyway (because they > import robjects rather than rinterface), May be this is because rpy2.robjects is currently the most visible option (rpy_classic is an other one). rpy2.robjects and rpy2.rpy_classic are implemented using rpy2.rinterface... but I would not pretend they are *the* way to have an API to R (there are points where for some users they suck by design ;-) ). > and since R actually cannot > be initialized/deinitialized/reinitialized anyway, True for the last two, but not for the first one. Example: import rpy2.rinterface as ri #call ri.set_initoptions() here import rpy2.robjects as ro (and I still have the hope that an embedded R can be stopped and restarted). L. > there isn't much > use in exposing the functions to do it. And it would make all this > stuff trivial. > > -- Nathaniel ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ rpy-list mailing list rpy-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rpy-list
