Nathaniel Smith wrote: > On Mon, Feb 9, 2009 at 11:07 AM, Laurent Gautier <lgaut...@gmail.com> wrote: >> 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). > > Yeah, IME python wrapping is all about writing the thinnest > barest-bones API possible in C, and then writing the user-friendly > interface in Python.
Writing C-level modules for Python is indeed a little tedious. > In this case it's just a question where to put > that user-friendly API, I guess (rinterface/__init__.py vs. robjects > and friends). If you want them in rinterface, then are you planning to > assign the variables at initialization time, like > > def initr(): > real_initr() > global MISSING > MISSING = getArgMissingSexp() > # repeat for NA_*, etc. > > ? That's one possibility. One thing I would really like to have is to have an error upon calling those variables while R is not initialized, and defining them in the module only upon initialization is one way I am considering (as defining getters/setters of some sort is probably not possible with modules). The other option would be to use a class. In any case, this is only holding as long as an embeddedR cannot be stopped (otherwise, how to invalidates those variables ?). May be not an immediate priority still. >> - 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). > > Makes sense. > >> 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 ;-) ). > > Oh, I'm well aware -- but there will still be a fairly small number of > such high-level interfaces, and their authors already need a bunch of > esoteric R knowledge, so providing them with a slightly less pretty > API is not really a barrier. Natural selection should limit them, but I am keen on making the API elegant nevertheless (as it may incitate, or I'd rather say "not turn immediately away", contributions to such API). I'd also like to point out that higher-level interfaces do not have to be only programmatic; experimentations with R GUIs would also be welcome (I keep hoping I'll have the time to make progress on that front). L. > -- 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
