Removing <body onload="brython()"> #2229

PierreQuentel · 2023-08-23T16:57:55Z

PierreQuentel
Aug 23, 2023
Maintainer

Hello,

Since the beginning of Brython, there have been 3 requirements to load Python scripts in the browser:

loading brython.js in the page
writing scripts inside tags <script type="text/python">
calling brython() in <body onload="brython()">

Commit 3793337 removes the 3rd requirement : you don't have to explicitely call brython() any more.

A typical Brython page would look like

<!DOCTYPE html>
<html>

<head>
<script src="/src/brython.js"></script>
</head>

<body> <!-- No onload="brython()" ! -->

<script type="text/python">
print('look, no onload in the body tag !')
</script>

</body>
</html>

To achieve this, the Brython engine now includes a mechanism that works this way:

when brython.js is loaded in the page, a list of all the scripts with type="text/python" already loaded is initialized as the array python_scripts
a DOM MutationObserver then tracks the other Python scripts loaded in the page after brython.js and adds them to python_scripts
brython.js adds an event listener on DOMContentLoaded: when the HTML page has finished loading, the program checks if the <body> element has a property 'onload'.
- if not, the property onload of <body> is set to function brython
- if yes, the onload callback is executed. If this callback called the brython function, stop here, otherwise call brython()

The change is backwards-compatible : if the page has <body onload="brython({debug=2, ...})>, the programs runs the same as before (except that the list of Python scripts has already been initialized, but this is transparent for the user).

If brython() is not called, the options such as debug, pythonpath etc. that were passed as arguments to brython() are now specified as attributes of the <script> tag. For instance, the debug level is specified as

<script type="text/python" debug="2">

At the moment this per-script options setting is only partially included (there is some work ahead to replace the current mechanism).

Feedback is as always much appreciated !
Pierre

lebalz · 2023-09-05T07:21:45Z

lebalz
Sep 5, 2023

Hi @PierreQuentel
This change is a big step forward to use Python even more straight forward to build websites 🥳

For my brython use-case, i'm wondering if the current behaviour still works:

I use brython for an educational page to embed editable and executable python blocks (and most importantly: in comparison to wasm alternatives, the turtle module can be used out of the box in brython...): https://ofi.gbsl.website (github.com).

I currently use the following mechanism to run python scripts only on demand:

Normally, all Python code has type="text/py_disabled" and only when executing the given code block, the script is set to type="text/python" (models/Script.ts#L205-L237)
To trigger the code to be executet, window.brython(1, 'script-id') is called as a reaction to the users click on the Execute-Button in the editor (PyEditor.tsx#L47-L49)
(To communicate between the python- and the js/react world, i'm using currently notifications and use a custom "Script-Template", that handles all the brython-specific stuff (CodeEditor/brython_runner.raw.py together with CodeEditor/PyScriptSrc.tsx#L35-L43))

I guess the second step will become obsolete through the MutationObserver and the change of type="text/py_disabled" to type="text/python" will instantly execute this block?

Thanks for diving in to my usecase :)

0 replies

ed2050 · 2023-10-18T11:21:00Z

ed2050
Oct 18, 2023

The new behavior is great. Nice job Pierre!

In some circumstances, you may want to manually invoke brython () after doing other setup. @lebalz gave one example. In my case, using brython in browser extensions, I use js to start brython when certain conditions are met to avoid the memory hit on every page (there are many many open pages).

Perhaps a parameter in the brython script tag could turn off auto-load? Something like :
<script src="brython.js" autoload="false"> </script>. brython.js could detect this flag on startup and revert to the manual brython () call.

0 replies

PierreQuentel · 2023-10-18T12:34:47Z

PierreQuentel
Oct 18, 2023
Maintainer Author

@lebalz and @ed2050

Thanks for the feedback !

In version 3.12.0 I have added and documented a couple of methods of the __BRYTHON__ object, available in Javascript, to allow more control of Brython scripts from Javascript programs.

For your use cases, you can use __BRYTHON__.runPythonSource(src[, script_id]) like that:

for scripts with type = "text/py-disabled" (@lebalz)

<button id="run_py_disabled">run text/py-disabled</button>

<script type="text/py-disabled" id="pyscript" debug=2>
print('run text/py-disabled', __name__)
</script>

<script>
document.getElementById('run_py_disabled').addEventListener('click',
  function(ev){
     for(var script of document.querySelectorAll('script[type="text/py-disabled"]')){
         __BRYTHON__.runPythonSource(script.textContent, script.id)
     }
  }
)

for scripts of type "text/python":

to block execution on page load, set ids to the empty string

<brython-options ids=""></brython-options>

once the page is loaded, you can run the scripts with brython({ids:[...]}), or use __BRYTHON__.runPythonSource()

     for(var script of document.querySelectorAll('script[type="text/python"]')){
       __BRYTHON__.runPythonSource(script.textContent, script.id)
     }

I think this feature is more flexible than observing attribute changes (from "text/py-disabled" to "text/python") or adding an option "autoload=false".

3 replies

ed2050 Oct 20, 2023

Thanks Pierre, that's great. Doesn't load brython scripts til you invoke them.

However I'm not sure if that addresses my issue. I don't want to start the brython intrepreter at all until a certain point. Running 'brython ()' seems to significantly increase the memory requirements on my pages. Memory usage on the page increases by 10 mb to 15 mb just by calling 'brython ()' without running any brython scripts.

It's a small amount when running a few pages, but I often have dozens or hundreds of pages open. Brython runs in a browser extension which runs on every page. I delay loading the brython interpreter on a page until a given keystroke, to avoid the memory penalty until I actually use the extension on that page (which may or may not be needed, depends on many dynamic factors).

Does your change support a way to not invoke the brython interpreter itself until needed? It's not clear to me from the syntax above. Seems like the interpreter loads as normal and just delays executing scripts.

Docs

Also, sorry to bring this up, but would it be possible to mark the docs with brython versions? Or access old versions of the docs online?

I often run older versions of brython for compatibility and testing reasons. If I read the docs, I wouldn't have any way to know that runPythonSource was just introduced in 3.12.0. This can cause confusion if someone uses a slightly older version and the documented functions aren't working.

Maybe like docs.python.org where new features are labeled with added in version 3.7 or something?

Thanks as always for your dedication and hard work!

lebalz Oct 20, 2023

Wow, thanks a lot @PierreQuentel for the examples and instructions! I'll check that out 👍

lebalz Feb 13, 2024

Works like a charm, thanks @PierreQuentel for the help 👍

PierreQuentel · 2023-10-20T13:21:20Z

PierreQuentel
Oct 20, 2023
Maintainer Author

I'm not sure to understand what you mean by "starting the Brython interpreter": does it mean loading brython.js in the page, or running brython() once the script is loaded ?

If it is the second option, in the example I gave, there was no call to brython(). A minimal example would look like this (the event being here a click on a button, it would probably be another event in your use case)

<!doctype html>
<html>
<head>
<meta charset="utf-8">
<script type="text/javascript" src="/src/brython.js"></script>
</head>

<body>

<brython-options ids=""></brython-options>

<button id="run_python">run text/python with querySelector</button>

<script type="text/python" debug=1>
print('run Python script')
</script>

<script>
document.getElementById('run_python').addEventListener('click',
  function(ev){
     for(var script of document.querySelectorAll('script[type="text/python"]')){
       __BRYTHON__.runPythonSource(script.textContent, script.id)
     }
  }
)
</script>

</body>
</html>

In the first case, here is another minimal example

<!doctype html>
<html>
<head>
<meta charset="utf-8">
</head>

<body>

<button id="run_python">run text/python with querySelector</button>

<script type="text/python" debug=1>
print('run Python script')
</script>

<script>
document.getElementById('run_python').addEventListener('click',
  function(ev){
     // load brython.js in the page
     var script = document.createElement('SCRIPT')
     script.setAttribute('src', "/src/brython.js")
     script.addEventListener('load', function(ev){
         // when loaded, run the Python scripts
         for(var script of document.querySelectorAll('script[type="text/python"]')){
           __BRYTHON__.runPythonSource(script.textContent, script.id)
         }
     })
     document.body.appendChild(script)
  }
)
</script>

</body>
</html>

0 replies

PierreQuentel · 2023-10-20T13:27:55Z

PierreQuentel
Oct 20, 2023
Maintainer Author

Also, sorry to bring this up, but would it be possible to mark the docs with brython versions? Or access old versions of the docs online?

Very good point ! Because of this radical change of removing "onload=brython()", in release 3.12 I have started to introduce this feature on brython.info:

the documentation for version 3.12 has a line "Documentation of version 3.12"
the address now has the version number inside : https://www.brython.info/static_doc/3.12/en/intro.html
if you manually change 3.12 to 3.11 you have the documentation of version 3.11 on line

This is still very rough, I will improve the interface in the next releases, something like on the python.org documentation pages

0 replies

ed2050 · 2023-10-21T12:58:02Z

ed2050
Oct 21, 2023

I did an experiment to verify my findings. Made a minimal html page on localhost. 3 versions of the page:

base version with no brython.js anywhere
passive version with <script src="brython.js"> in header, but no brython () calls (so brython script loaded but interpreter not running)
active version with both <script src="brython.js"> and <body onload="brython()">, but no python scripts in the page.

Here is the memory usage of each page according to Chrome (Total JS Heap Size in dev tools Memory tab):

base 40.3 MB
passive 48.7 MB
active 49.2 MB

Tested with both 3.8.9 and 3.11.0. Numbers differ slightly but pattern is the same.

Results

So the biggest memory hit actually isn't from invoking brython(). It's from loading brython.js in the <script> tag. And then whatever memory your python scripts themselves use.

My mistake was thinking that delaying brython() affects memory size, when it has very little impact. Most savings is from not execting my scripts, which is triggered by brython().

Conclusion

The changes proposed above are fine, shouldn't impact my use case.

I could save more memory by not inserting <script src="brython.js"> in the DOM until I'm ready to execute my scripts. But that's a separate issue, not affected by changes to brython ().

2 replies

PierreQuentel Oct 21, 2023
Maintainer Author

Thanks for the information Edward. Do you also load brython_stdlib.js in the page ?

ed2050 Oct 22, 2023

No I don’t use stdlib in this app. Experiment above does not use stdlib.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Removing <body onload="brython()"> #2229

{{title}}

Replies: 6 comments 5 replies

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

Select a reply

Removing <body onload="brython()"> #2229

PierreQuentel Aug 23, 2023 Maintainer

Replies: 6 comments · 5 replies

lebalz Sep 5, 2023

ed2050 Oct 18, 2023

PierreQuentel Oct 18, 2023 Maintainer Author

ed2050 Oct 20, 2023

Docs

lebalz Oct 20, 2023

lebalz Feb 13, 2024

PierreQuentel Oct 20, 2023 Maintainer Author

PierreQuentel Oct 20, 2023 Maintainer Author

ed2050 Oct 21, 2023

Results

Conclusion

PierreQuentel Oct 21, 2023 Maintainer Author

ed2050 Oct 22, 2023

PierreQuentel
Aug 23, 2023
Maintainer

Replies: 6 comments 5 replies

lebalz
Sep 5, 2023

ed2050
Oct 18, 2023

PierreQuentel
Oct 18, 2023
Maintainer Author

PierreQuentel
Oct 20, 2023
Maintainer Author

PierreQuentel
Oct 20, 2023
Maintainer Author

ed2050
Oct 21, 2023

PierreQuentel Oct 21, 2023
Maintainer Author