On Tue, 2008-10-14 at 16:39 +0100, Peter wrote: > > Not completely, but I clearly overlooked the fact that such backward > > compatibility through import statements are common practice in Python. > > That's an interesting suggestion from Andrew... let me think on how I > > can tie that together. > > > > I am also seeing two separate points here: > > - provide the '.'-to-'_' feature as an option for rpy2's robjects > > This would be nice for those of us used to the old rpy1 name mapping - > but I can see we you don't want it as the default. > > > - provide full/limited backward compatibility with rpy-1.0 as a module > > (so legacy rpy code can run as such) > > This does seem to be a useful feature to have. However, if rpy1 will > continue to be maintained and updated for each new R release for say a > year (in parallel with rpy2), this is less important.
One of the aim is to allow projects to be migrated progressively to rpy2. Both interfaces could be used during that transition period, and in a way that is not possible with both rpy and rpy2 installed. With rpy2.robjects and rpy2.rpy_classic, the underlying layer is rpy2.rinterface for both and the same R-level objects can used from one interface or the other. That's the ideal picture; unfortunately I did not spent so much time on rpy2.rpy_classic (and I am unsure of how much more I will spend on it before release). An other aim is to demo how to implement a new interface to R using rpy2.rinterface. > >> Earlier in this thread Laruent wrote: > >> > There is also a module "rpy_classic" that is a rough emulation of rpy > >> > built with rpy2.rinterface (the emulation is rough because of limited > >> > time on my end - this is also a demo of how how could build an interface > >> > to R without touching on C code). > >> > >> If this can be tested, then it sounds like it should be the recommended > >> route for converting rpy1 code for rpy2. > > > > May be not what you are expecting. The aim of rpy_classic is to have rpy > > code running without (much) modification. > > Could you clarify what you mean by "The aim of rpy_classic is to have > rpy code running without (much) modification." Do you mean old rpy1 > code, or something different? rpy1 code. unmodified. > I was making an assumption based on the name that the rpy_classic > module would provide "classic" (i.e. "old fashioned") rpy behaviour, > but this doesn't seem to be what you mean. In that case appearance is deceptive. ;-) rpy_classic aims at being a reimplementation of the rpy interface using rpy2.rinterface. I guess that I was not very clear, and hopefully this is now getting better. best, L. > Thanks, > > Peter ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ rpy-list mailing list rpy-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rpy-list
