@kwargs hard to understand, insidiously incorrect runtime results

[JohnDenker]

Recipe:
Consider the following tiny program, based on the one in issue #6, with minor improvements

###@kwargs
def sum(x=0,y=0,z=0):
   return 0+x+y+z

print('should be True:', sum(z=5, y=3) > 0)
print('should be 8:   ', sum(z=5, y=3))

Desired and expected behavior:

should be True: True
should be 8:    8

This works as expected under python from the command line.

Observed glowscript behavior:

should be True: false
should be 8:    0[object Object]00

This is 100% reproducible chez moi. The source code looks reasonable, works correctly under python, and compiles without error under glowscript, yet produces a hard-to-explain answer. Bugs of this sort are exceedingly painful to track down.

The first line of output demonstrates an insidious failure.

If we understood the second line, it would explain the first line, but the second line itself is very hard to explain.

Note that the @kwargs "decorator" is not permitted in real python.

Inferior Suggestion:

In a function prototype, if there are "=" signs in the formal argument list, and if the compiler is not going to generate well-behaved code, then the preprocessor should throw an error. It should be easy to detect this situation.

A compile-time error is infinitely preferable to insidiously incorrect run-time results.

Much Better Suggestion:

If we're going to go to the trouble of detecting "=" signs in the formal argument list, we might as well generate the correct code. If necessary, the preprocessor can stick in the @kwargs for the benefit of later stages.

To say the same thing the other way: Asking the user to write @kwargs in the source seems unhelpful.
a) It is laborious and error-prone;
b) it is unnecessary AFAICT; and
c) it makes the source less compatible with real python.

[JohnDenker]

Also note that after careful looking, even knowing exactly what to look for, I was not able to find anything in the documentation that says that unadorned def sum(x=0,y=0,z=0) might not be not permitted in glowscript.

As a related point, bug #6 is the only reference I could find to @kwargs. Expecting users to read all the old closed bugs before writing code would not be reasonable.

[BruceSherwood]

I agree that this situation is bad, as are the 0 and false issues you just reported. I am cautiously hopeful that invoking a newer version of RapydScript, called rapydscript-ng, will improve the situation significantly. A fundamental problem is that the original rapydscript project has stalled, with no updates for many months. The ng version, by Kovid Goyal,, who is highly productive and responsive, appears to move closer to standard Python than the original rapydscript. Trying ng is a high priority, but it's not an easy thing to do (or I would have tried it some months ago), and I've been heavily involved, with Ruth Chabay, in making Jupyter Python mature, with the same API as GlowScript VPython (and implementing missing objects in GlowScript such as the recently released 3D text object, to be added to the Jupyter version.

The test cases you've provided will be useful in testing ng. Thanks.