Nathaniel Smith wrote: > On Wed, Sep 30, 2009 at 8:08 AM, Laurent Gautier <lgaut...@gmail.com> wrote: >> Nathaniel Smith wrote: >>> IMHO, if you're wondering about the case where *both* are valid, then >>> you've already lost. If you're wondering that, then it means you're >>> trying to handle the case where function A takes foo.bar, and function >>> B takes foo_bar, and you want to be able to call both A and B and have >>> the interface magically know how to munge the argument name for each. >>> But how can it possibly know in a reliable way? "In the face of >>> ambiguity, resist the temptation to guess." >> No what I mean is what are doing in the case of a function with a signature >> like (foo.bar=1, foo_bar=2) ? > > I know what you mean, I'm saying that if you're designing a system > where that's a tricky question then IMHO you've already made the > system too complex. > > For my approach (unconditional _ to . conversion) the answer is > trivial: you use rcall, just like you use for any other function with > an underscore.
This is all an interesting discussion, and I can hopefully get into something nicer for rpy2 (and rpy2-based interfaces). There is I think agreement that the absence of conversion is safe. (note: an interesting side note is that I wrote method rcall() to also address an other difference between R an python: named arguments are ordered in R (and can be mixed with unnamed argument). Unless I am mistaken, the issue is how to "convert" R names containing "." into variable names valid in Python (in order to expose them more naturally in Python - a syntactic sweeter, if you will). >> I am precisely advocating the absence of guessing, and be "better safe than >> sorry" > > I can't quite tell what you're advocating -- it seems to me that there > are two options that do not involve guessing: > -- no conversion > -- unconditional conversion > In both cases we just document "this python code corresponds to this R > code. Always. It does not depend on the function called, the phase of > the moon, or the price of tea in china". > > But you don't seem to really like either of these, and you don't like > guessing, so I'm not sure what you do want :-). My point is more that the aforementioned rules might be deceptive in situation mentioned (names in the R space only differing by "." and "_"). Even if that situation is not the most common, I still think that it should be avoided as much as possible by default... If educated guess there is, it should be happening with safeguards. note: There might be a slight misunderstanding btw; I am perfectly fine with the absence of conversion, as this is currently what is in place, but I'd like to see if a (safe) step toward conversion can be made. >>> 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. > > I know. But ggplot2 is still an oddity, even for new code -- the old > technical limitation set the convention, and it's still followed by > sensible coders. Not everyone is sensible, alas, but for a convenience > API I'd rather handle 95% of case than 75%. I would certainly not judge a coders' R common sense by its use of '.' over '_' in symbol names (and I want to believe that this has nothing to do with the fact that I used R for a fair number of years, yet switched progressively to the use of '_' - I am using a number of other languages, and the use of '_' in symbol names is allowed in all of them while the use of '.' is only allowed in R). >>> 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" ??? > > Not sure what you're trying to imply with your triple-question-marks > :-), but yes, that's what I meant. Because it's much more common to be > calling a function that uses . than to be calling one that uses _. Typographic expression of incomprehension or incredulity rather than a proper question, or "?!" if you prefer ;-) How common this is will depend on what each one is calling in R. L. > -- Nathaniel ------------------------------------------------------------------------------ Come build with us! The BlackBerry® 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-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ rpy-list mailing list rpy-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rpy-list
