A possible way to improve code readability and to facilitate code maintenance/refactor ?

[denis-migdal]

Currently, for performances reasons, some parts of the standard Python library is implemented in JS.

However, this has several limitations :

• the JS code isn't necessary easy to read.
• if Brython changes its helper functions or internal representations, this would require to update all of this JS code.
• this may be source of errors.

My suggestion would then to write such code in Python, and to transform them into JS with slightly different ast2js rules. Brython would distribute the pre-generated JS files, i.e. not requiring the developers to generate them.

We could then define some standard python classes/functions with Python code, e.g.:

from JS import eval

class str:
     def replace(self, search: str, value: str) -> str:
          # do stuff
          assert True
          # can also write JS code :
          JS.eval("console.log('hi ;')"); 
          # maybe doing some stuff with f-string :
         return JS.eval(f"${self}.replaceAll(${search}, ${value})"); 

Would generate something like :

// do all the Brython class/method declaration suff.

function replace(list, search, value) {
         // python stuff converted into JS - with some different ast2js rules
         _b_.assert(true);
          // JS.eval() calls are directly replaced by the JS code.
         console.log('hi ;');
         return _b_.jsobj2pyobj( _b_.pyobj2jsobj(self).replaceAll( _b_.pyobj2jsobj(search), _b_.pyobj2jsobj(value) ) )
}

In few weeks, I plan to use this in SBrython, so I may write lot of python files that could be reused by Brython. For the JS conversion, I assume that Brython would prefer to write its own ast2js rules instead of relying on SBrython.

@PierreQuentel What do you think ?

[PierreQuentel]

In theory, I like the idea. But the perpective of rewriting huge modules like python_re.js in Python without knowing if the performance will be the same scares me...

[denis-migdal]

We could do the following:

1. Rewrite some short modules, while temporary keeping the previous version.
2. Add a temporary development flag to use the previous version if needed.
3. Letting the big and problematic modules as they are for now.

For the next weeks, I'll continue to work on stubs file for the JS API (that you could also use to check their call and print better usage error message).

Then I'll work on the py files for Python standard library in SBrython, which would allow us to test the idea (and to continue or give up).

Also, for the functions/methods that are too slow, this could be interesting to have a "@wasm" decorator to generate wasm code instead of JS...

This would have several advantages, and there are several ways to do it... with some ast2asm rules... But that's more work for us to do...

There are 3 possibilities :

1. directly generate wasm binary.
2. generate JS with some type hints, and then convert it into WASM.
3. generate in a compiled language, e.g. C++ and then convert it into WASM.

For SBrython I plan to have a TS output (so JS with type annotations), so this might be enough to generate WASM, but we'll need to test it (and benchmark it).

I hope I could put some student on it next year... but didn't have any this year.

[denis-migdal]

Finally, I may not do this in the immediate future.

I did not found a simple way to use it when we want to inline the methods calls (I need that for some builtin classes in SBrython).

I'll post update here when I'll work on it.