[George Sakkis] > Allowing non-default arguments after *varargs doesn't make sense,
In R, one may use the ... format argument anywhere in the argument list, but may later test if a non-default argument was provided or not. I tend to write R a bit like I would write Python, but hopefully, I'll eventually understand R enough that I could break that habit. > > keywords may be abbreviated, and much more hairy, > Hmm.. -1 on this. It may save a few keystrokes, but it's not good for > readability and maintenability. That was my first impression too. Yet, interactively, I found that feature very convenient. Already with Python, I use shortcuts interactively that I would not write nor keep in real, saved, permanent programs. And for very common functions and features, which are not really fluctuating anymore, some abbreviations became well known idioms. > > the computation of actual expressions given as arguments is lazily > > postponed until their first use within the function. > Is this like an implicit lambda before each argument ? Not exactly true, but that's surely a way of understanding it. Such things are not new: I first saw them in Algol-60, except that once an argument has been evaluated, it is cached and not evaluated again. It's true that in R, much more than in Python, evaluation of an argument may often be computationally expensive. Moreover, in R, the initial writing of the argument is preserved on the form of a parsed tree which can be operated upon. This allow for strange things (at least for a Python eye), like computing the symbolic derivative of an argument. I toyed with this facility to build mathematical images, and then, animations. For an exemple, see: http://pinard.progiciels-bpi.ca/plaisir/NRart/ and from there, click on `nr.image' near the end. > If so, why does it have to be restricted to function arguments ? It > seems to me that argument passing and lazy evaluation are orthogonal > dimensions. In R, laziness is automatic while calling functions, but not otherwise, and from what I saw so far, less meaningful in other contexts anyway. However, I think laziness is available explicitely if needed (there is library function that returns a "promise" of its argument). > Or for a more exotic use: > def prologLikeSum(a=s-b, b=s-a, s=a+b): > return a,b,s > prologLikeSum(1,2) == prologLikeSum(1,s=3) == prologLikeSum(b=2,s=3) == > (1,2,3) This is exactly how R people use the feature most of the times (at least so far that I naively saw, as I'm still pretty new at all this). > This seems pretty hard to change though. Oh, I would not even dream about it for Python. The idea would have to make its way first within the developers, and this might take years, if ever. The best I (we) could do is keep the idea in the air, for a good while. It would likely never survive all the debates it would generate. But who knows! :-) > [...] and even worse, [bindings] would have to be computed for each > call, as the prologLikeSum example shows. Yet, already, as it stands, argument passing in Python is not innocuous. A bit more, a bit less, nobody would notice! :-) -- François Pinard http://pinard.progiciels-bpi.ca -- http://mail.python.org/mailman/listinfo/python-list