Serious function argument bug?

[Bruce Sherwood]

I don't see anything in the documentation that would indicate that the handling of arguments to functions is very different from that in Python, so the following looks like a serious bug in handling argument passing. This of course also affects passing arguments to __init__ of a class.

def f(a=[10,20], b=[30,40]):

    console.log(a)

    console.log(b)

        

f(b=[1,2],a=[3,4])

compiles to the following:

function f(a, b) {

    if (typeof a === "undefined") a = [ 10, 20 ];

    if (typeof b === "undefined") b = [ 30, 40 ];];

    console.log(a); # Incorrect (should be [3,4]): Object {b: Array[2], a: Array[2]}

    console.log(b); # Incorrect (should be [1,2]): [30, 40, append: function, ......

}

f({b: [ 1, 2 ], a: [ 3, 4 ]});

but it should compile to this:

function f(args) {

    var a, b;

    if (typeof args.a === "undefined") a = [ 10, 20 ];

    else a = args.a;

    if (typeof args.b === "undefined") b = [ 30, 40 ];

    else b = args.b;

    console.log(a); # Correct: [3, 4, append: function .....

    console.log(b); # Correct: [1, 2, append: function .....

}

f({b: [ 1, 2 ], a: [ 3, 4 ]});

[Alexander Tsepkov]

Bruce,

This is not a bug. The keyword arguments indeed work differently than in Python, and documentation explains it (see this section: Keyword Arguments (**kwargs)). This is done to avoid extra overhead, since more than 90% of the functions you write would not make use of it. For the behavior you want, you'd want to use @kwargs decorator (part of stdlib), which would then solve this problem for you.

[Bruce Sherwood]

Thanks for the explanation. I apologize for missing that aspect of the documentation.

Could you please give a simple example of how to use the @kwargs decorator? Thanks.

[Bruce Sherwood]

Dumb. You give the @kwargs decorator example in the documentation.

Incidentally, I appreciate the good job you've done with the documentation. It's my fault that I've erred several times now in assuming a bit too much exact equivalence between Python and RapydScript without reading more carefully.

[Alexander Tsepkov]

Not a problem. I try to update documentation as soon as I add a new feature, precisely because of these minor yet possibly annoying differences with Python. I do get asked about these differences with Python quite a bit, and my answer is basically that I don't force Python features when they detract from JavaScript's own pros. For example, like JavaScript, RapydScript makes it easy for users to pass anonymous functions around, and having kwargs be automatic felt like it would be detrimental to that.

This is why I emphasize in the beginning of the documentation that RapydScript is not pure Python, and I'm glad to see that you're ok with that. The goal is to bring the joy of Python to JavaScript, not force JavaScript to be something it's not. I've written a blog post on this topic a while back as well: http://blog.pyjeon.com/2014/01/18/what-is-pythonic/

[Bruce Sherwood]

I agree very much with your design criteria and approach, Alexander. Other Python -> JavaScript projects I've looked at, that have as a goal following Python exactly, can be useful for introducing novices to Python in a browser, but they are so slow as to be useless in the kinds of situations that GlowScript (like VPython) are designed for. Your blog entry is thoughtful.