Peter wrote:
> On Wed, Sep 30, 2009 at 4:08 PM, Laurent Gautier <lgaut...@gmail.com> wrote:
>>> For my own use, I looked around, and couldn't find any functions that
>>> had _ arguments, and lots that had . arguments.
>> Older R code did not have _ (because it used to be an invalid character
>> for regular symbol, as _ was an alias for "<-").
>> More recent code have. For example, ggplot2 only has _ in paramter names.
> 
> This change to R is a real pain for us rpy(2) users :(
> 
>>> So I declared that _
>>> to . conversion is an unconditional part of the convenience wrapper
>>> interface, comparable to data type conversion. (I also declared that
>>> trailing underscores are stripped -- to make functions like 'class'
>>> and 'print' accessible -- and the word 'dollar' becomes '$'.)  These
>>> rules are simple, predictable, correct in vastly more cases than doing
>>> no conversion, and for the occasional weird edge-case you can still
>>> use rcall just like now (only the weird edge-cases are much rarer).
>> "correct in more cases than doing no (name) conversion" ???
> 
> Can you do something like check if example_name is a valid argument
> for the function at run time, and if not, check example.name instead?
> Would this impose too high a performance cost?
>
> I agree this won't cover the special case of a function which has
> two arguments which differ only in underscore vs dot, but that is
> very rare corner case (surely)?

I welcome all proposal, but I'd like to keep users on the safe side by 
default as much as possible (starting with "it should not happen... most 
of the time" does not seem like the right way to start).
rpy2.robjects can already be customized to do that, and there is also
rpy2.rinterface so one can write easily the automagic system wished.



L.




> Peter
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> rpy-list mailing list
> rpy-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rpy-list


------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
rpy-list mailing list
rpy-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rpy-list

Reply via email to