What happened to Pyjeon/RapydScript?

[v3ss0n]

So this is continuation of pyjeon's Rapydscript ? Why not a fork there ?

[v3ss0n]

just read the bottom of the change list, very well. and since Pyjeon's Rapydscript is practically dead , i think this should become main . So many new features compare to original.

[kovidgoyal]

You'd have to convince @atsepkov to relinquish maintainership of the original rapydscript for that to happen. When I first made this fork, he had no intention of doing that. So we decided I would continue working on -ng and he would merge in the changes from here as and when he found the time. Since then, he does not seem to have found much time -- but I have no idea whether he is willing to relinquish maintainership or not.

[atsepkov]

Kovid, that's not true. I've offered to give commit rights to original RapydScript multiple times. It was your decision to keep the forks separate, I still have the emails with that conversation. At this point I realize that the fundamentals of the language may differ too much to allow for a merge. With that said, you're still welcome to the write access for the original RS, if you desire it. What I don't want to do is delete it altogether in favor of this version, which doesn't even seem to have been forked properly.

[kovidgoyal]

I dont know what I would do with write access to the original repo, unless you are actually ready to merge in all the code from rs-ng, in particular the backwards incompatible changes. When we discussed this originally, you were not ready to do that. Has that changed?

Let me remind you that I only created rapydscript-ng after you said you were not willing to merge in all the changes I was making. And despite that decision, I have been scrupulously adding links to every single commit that fixes an open bug in the original RapydScript so that you can merge them in easily, despite the diverged codebases.

[atsepkov]

I understand, what I'm saying is I'm not simply being stubborn for the sake of being stubborn. I want to make sure other projects relying on original RS (including GlowScript) remain functional. There are many parts of your version that I've accepted back into original. There are, however, also parts that I prefer from the original version instead (such as the less-intrusive kwargs, performant true equality operator, and smaller baselib footprint). If we can address these issues in the merge, and figure out how to make RS still relevant in ES6 world, then I'm all for it.

[kovidgoyal]

The whole point of having a 0.x version number is that you have the freedom to break backwards compatibility. So IMO trying to preserve backwards compatibility should not be an overriding concern. If there is a good reason to break backwards compat, then it should be broken. For projects that are not willing to migrate their code, old releases of rapydscript remain available.

Now coming to the other points you mention:

1. less instrusive kwargs -- I dont understand this one at all. If anything the kwargs implementation in rs-ng is less intrusive, in that it does not require a magic decorator in order to support kwargs. Not to mention that its support for *args and **kwargs is far more robust and closer to that of python.

2. == operator. If by this you mean converting == into a === b || typeof a === 'object' && rich_compare(a, b) let me point out that:
   a) I already merged that into rs-ng with a link to your blog post in the commit, so you get the credit
   b) Your implementation is broken if b is an expression that has side effects for example, a == do_something() where do_something() has some side effect and returns a value. This is fixed in rs-ng

3. Smaller baselib footprint -- on this I'm afraid we disagree. To me, providing a consistent runtime environment that has the fundamental container types: string, list, set and dict, as well as important python global functions is more important that saving a few KB in baselib size. The overhead of trying to make all those parts of the baselib into optional dependencies is so high that it simply will not happen -- at least, I dont have the energy/motivation to make it happen.

[kovidgoyal]

Oh and as for relevance of RapydScript in an ES 6 world. My personal motivation for using RapydScript is that, as a python developer who also has to write lots of JavaScript, my productivity is much higher when that JavaScript can be written in a language close to python. That motivation is not affected by ES 6, at all.

[v3ss0n]

I hope my issue doesn't lead to a flame-war. I am sorry, I didn't knew any of communication issues between two maintainers. But to voice my opinions why Rapydscript is important and keep you guys working :

• Javascript sucks , ES6 can't help. Python is better than javascript in almost every way possible.
• Rapydscript and Rusthon's JS are only true serious Python transpilers for Javascript.
• These days , javascript become main language for client-side programming at web, we are left without choices, front-end LOC in javascript become 2x-3x more than serverside Python .

So guys , please continue working on Rapydscript and also RapydML . You will save a lot of Python Developers' Life. I hope There is no need for in-fighting .

[kovidgoyal]

Dont worry, this is not a flame war -- the question is simply whether @atsepkov and I can reach a compromise that allows us to merge the two codebases. If not, things will continue as they have been. I fully intend to keep working on rs-ng, as I use it extensively in my other projects.

[v3ss0n]

So it seems , this is an inevitable fork then.

as a user , here are my opinions

• Javascript frameworks are now huge , over megabytes , for pyjeon there is no problem of increasing a hundred kilobytes, if Its going to save hundreds of hours of developers and better experience and functionality for end-user. Even at developing Asian country like ours , average connections speeds are 3MB/s now . There is no point saving a few hundred kilobytes at all.

Oh and as for relevance of RapydScript in an ES 6 world.

• I can't agree more , javascript at larger scale is un-maintainable at best , we really need rapydscript , even with best practices in javascript/typescript with full object oriented , compare to python, just modular python functions are much much easier to maintain, RS is very relevant in JS6 world , especially huge projects .

[v3ss0n]

there is a good reason to break backwards compat, then it should be broken. For projects that are not

I have never seen a release of RapydScript so , i believe nobody would care if it breaks backward compatilbity , as old version user won't even update as they do not see any release at all.

[atsepkov]

@kovidgoyal the kwargs decorator has been replaced by a more subtle system almost a year ago. The kwargs decorator has been unnecessary since then, the new system automatically curries the individual call in kwargs when it sees ** unary prefix for the last argument. I.e.:

args = {'foo': 1, 'bar': 2}
test(**args)
-----
var args = {'foo': 1, 'bar': 2}
kwargs(test)(args)

There are also other subtle differences between the forks, such as magic function JS() being replaced with magic string and some others I may not be aware of. Some of these changes seem like a matter of individual preference and neither is compatible with Python. For these changes I'd want some sort of sanity check from the community first. And sure, the community may not be large/vocal enough, but I'd want incompatible changes to at least consider the use cases of other developers, I'm more than happy to provide my own, despite being less active in development now. @BruceSherwood has been providing feedback on RS through its evolution as well.

As for ES6, I agree that it will not clean up JS. However, it introduces features like list comprehensions, generators, and classes, many of which RS had to implement manually. Now may be a good time to simplify the language to make use of new ES6 syntax sugar when possible, and solutions like Babel.js may make backwards compatibility irrelevant.

[kovidgoyal]

The kwargs support I am talking about is more than just support for **kw, it means being able to do the following:

def a(a, b=1, c=2):
  return [a, b, c]

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

Which you can do in rs-ng but not (at least the last time I checked) in RS without using the kwargs decorator.

Now to next point you raise:

JS() is a magic function. The problem with magic functions is that they break user code. Using a function for JS literals means that name JS cannot be used in user code and can even lead to subtle and hard to debug errors if the user uses that name without realizing the compiler is going to replace it with a javascript literal. For instance suppose the user uses an external javascript library that defines a function named JS() and then he calls it in RapydScript as JS('1'). that would become '1' in your fork instead of the result of calling the function JS() with the argument '1'.

Using a string literal for JS on the other hand is not magic. It has far less potential for user surprise, and does not restrict user code in any way. It is backwards incompatible, but for a good reason and is moreover a backwards incompatibility that is trivially caught by the linter I developed. In fact there are many more magic compile time function in original RS that I have converted to functions in the baselib, so that they are no longer magic, but instead simple global functions. For example, bool()

There is no backwards incompatible change I have made in rs-ng without a good reason. You are free to disagree with those reasons, but kindly do not dismiss them as personal preference.

You have not provided any reasons (as far as I can tell) for why you think the kwargs implementation in rs-ng is "more intrusive"? So can I assume you are OK with it? If not, I'd like to hear some reasons. If they are good reasons I am perfectly willing to change the implementation in rs-ng to address your concerns.

Similarly, you did not respond to 2) and 3) above, so can I assume you are OK with those as well? I am trying to nail down what exactly are your reasons for not wanting to merge, beyond the generic waiting for community feedback. If you do actually want community feedback perhaps you should ask for some -- make a new issue in the RS github project asking for feedback or a post in the RS google group. As it stands now, nothing will happen and the current situation will go on forever. Which is a pity for the RapydScript community.

Incidentally, at least @BruceSherwood seems to be happy with the changes in rs-ng, see #12

[atsepkov]

Both of those cases are handled as well (first case doesn't need kwargs):

def a(a, b=1, c=2):
    return [a, b, c]

a(1, b=2) == [1, 2, 3]
----
function a(a, b, c) {
    if (typeof b === "undefined") b = 1;
    if (typeof c === "undefined") c = 1;
}

kwargs(a)(a, {b: 2}) == [1,2,3]

The limitation in your version I didn't like was that function declaration required optional arguments to be considered a kwargs function, my version does not.

For #2, yes it sounds like your solution is good, haven't played with it

For #3, I'm not a fan, but don't have any solution to propose at the moment that's a good compromise.

For other magic functions like bool(), maybe I'm too anal about the performance overhead of a function call, I just don't want RS user to feel like they're taking a performance hit over JS user, I've often felt like that when using other Python-in-a-browser solutions, but JS today is much faster. Still, if I was to put that bool() in a loop, it would be quite a bit slower than !! which will be used by a JS dev.

[kovidgoyal]

That is good, if your kwargs implementation does support all the feautures of mine without needing the function declaration to have keyword arguments, then it is clearly superior, and I have no problem whatsoever with adopting it.

As for magic functions, IMO, people that require that last iota of performance from bool(), can always use literal javascript inline. I dont think that sort of optimizations should be baked into the language at compiler level. It's confusing why you cannot re-assign bool to your own custom function if you need to. In general I am not a fan of this kind of magic.

So to summarize, your remaining objections are:

1. kwargs -- I am happy to switch implementations, if yours is indeed a superset of mine

2. baselib size -- are you willing to live with the expanded baselib in rs-ng? As I dont see how any other type of compromise is possible there.

3. Community feedback -- all I have heard from the community about rs-ng is positive, but if you wish to seek more feedback before merging, you are welcome to do so. I just urge you to not put off the merge forever because of this reason.

4. Magic functions -- I think from your tone you are ok with making them global functions?

Anything else?