On Wed, Apr 22, 2009 at 10:33 PM, laurent <lgaut...@gmail.com> wrote:
> On Wed, 2009-04-22 at 12:16 -0500, Bo Peng wrote:
> (...)
I apologize for the wording of my previous email, which was sent, less
than politely, out of my extreme frustration over a software I had
high expectation. However, if you consider all the frustrations
misuses of rpy2 and do not see bugs or feature requests there, I will
not bother you again with them.
>> If the correct answer is r('R.Version()').subset('svn rev')[0][0], I
>> have to say that rpy2 is not for me.
>
> 1- There is not "one correct answer". There are several ways to achieve
> it. Other options are :
>
> ro.r('R.Version()[["svn rev"]]')[0]
> ro.r('R.Version()').r["svn rev"][0][0]
These look as ugly as r('R.Version()').subset('svn rev')[0][0]. I do
not want to go into all the technical complexities here because they
are irrelevant in terms of user expectation. Essentially speaking,
R.Version() returns a list of strings identifiable by keys so users
expect something like a dictionary, even if it is something wrapped
around a R object.
-- If R.Version()[["svn rev"]] returns '12345' in R, users will expect
'12345' in rpy. The [0] part is simply redundant and makes me wonder
what is [1].
-- If r('R.Version()') returns the whole dictionary-like object, it is
natural to expect r('R.Version()')['svn rev']. Users will have to know
a lot about rpy2 to write something like r["svn rev"][0][0].
Compared to r('R.Version()')['svn rev'] in rpy, the syntax in rpy2 is
extremely difficult to understand.
> 2- rpy is still around.
I hope that it will continue to be maintained for future versions of
Python and R.
>> 1. rpy_classic is not the same as rpy.
>
> This is not a complete implementation of the rpy API because of:
> - limited resources
> - apparently a limited demand
> Contributions have not been many.
As the maintainer of another open source object, I do understand all
these but please indicate clearly the differences between rpy_classic
and rpy in the documentation.
>> 2. The R vector etc are too complicated to use, and I do not see any
>> benefit of using them.
>
> Watch closer, I'd like to say.
I looked through the rpy2 documentation and I could not find an answer
to questions such as what is lacking in rpy, what problems rpy2 is
trying to address, what are the advantages of rpy2 over rpy, and in
which way users will benefit from rpy2. Instead, I saw you were
motivated by some alternative implementation (??) of rpy. My guess is
that this implementation allows rpy2 to expose internal R objects as
native Python objects. These are of course not a bad thing but I would
like to know how exactly normal users would benefit from this
approach, at the cost of all the syntax complexities/oddities.
>> 3. The rpy_object stuff is almost useless without support for the . to
>> _ conversion, because there are so many functions in R with .
>> (dev.off(), as.xxxx()...).
> It's straightforward to implement for yourself. Where is the/your
> problem ?
I had contributed to rpy before and I am still listed as one of the
developers. However, I need to be persuaded that rpy2 is better than
rpy to invest my time on it. Right now, I am afraid that rpy2 might be
designed around technical possibilities, not users' need.
Cheers,
Bo
------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
rpy-list mailing list
rpy-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rpy-list
