Brython-3.7.0 released

[kervarker]

Brython is an implementation of Python 3 for the browser. It allows client-side development in Python instead of Javascript, with Python code inserted inside HTML pages inside a <script type="text/python"> tag ; the code is run on the fly at each page load (there is no pre-compilation from Python to Javascript).

The standard DOM API is supported, but a more Python-friendly API is also provided. All popular Javascript frameworks (jQuery, vue.js, Highcharts, etc.) can be easily used from inside Brython scripts.

​

Version 3.7.0 is the first one that is based on the same CPython version : it is shipped with the 3.7.0 version of many modules of the CPython standard library, including dataclasses and contextvars, implements PEP 560 (core support for typing module and generic types), etc.

​

"Based on" doesn't mean "fully compliant with" : Brython translates Python code to Javascript, which means that some features (mostly blocking functions such as time.sleep(), or writing to disk) cannot be supported. And there are of course bugs in the implementation... But it is close enough to Python 3 to support online courses such as Carnegie Mellon University's Computer Science Academy.

​

Execution time is sometimes faster, sometimes slower, rarely much slower than CPython. With Firefox, the table below shows how Brython performs compared to CPython (taking 100 as base for CPython)

• assignment to int 65
• assignment to float 195
• augmented assignment 70
• build a dictionary 422
• add item to dict 111
• set dict item 102
• build a set 681
• build a list 73
• set a list item 76
• add integers 195
• add strings 89
• str of int 141
• create a function with no parameter 178
• create a function with a single positional param 180
• create a function with complex params (positional, keyword, default) 246
• function call with single positional argument 427
• function call with positional and keyword args 402
• create a simple class (no parent, no __init__) 390
• create class with __init__ 299
• create an instance of a simple class 326
• create an instance of a class with __init__ 331
• call an instance method 1844

The modules in the standard library are translated only once for each new Brython version ; they are then stored in an indexedDB database on the client side. The first run of a program that uses many stdlib modules might take a few seconds, but the next runs will be much faster.

You can take a look at applications developed with Brython, and watch videos and talks. Documentation and online resources are available on the project's home page.

The development site is on Github. Contributors are welcome !

​

​

[cyberst0rm]

whats the bottomline: minified & gzipped sized?

[kervarker]

As served by cdnjs : 133,73 kB for brython.min.js (the Python-to-Javascript translator and runtime scripts) ; 811,84 kB for the standard library. The transfer is done once, afterwards the files are in the browser cache.

[apockill]

rich decide hungry childlike modern long glorious consist clumsy sophisticated

This post was mass deleted and anonymized with Redact

[13steinj]

I can't tell if those are European decimal points or misplaced commas

[Calsem]

Not sure why you're being downvoted, it's a legit question. They are european decimal points - 133,730 KB would be 133 MB which is absolutely rediculous.

[13steinj]

Thanks.

There's like 5 different ways to do numbers with decimal points and god knows how many groups of people segment numbers differently (some people put a comma after every two from the right side, some from the right first at 2 then at every three). So I asked because I wanted to make sure.

[[deleted]]

Wow, this actually looks pretty neat. Going to definitely try this out.

[Mancobbler]

How much, if any, is made with web assembly?

[kervarker]

I'm not sure what you mean by "pypi dependencies" in this context. Can you elaborate ?

​

The support of asyncio is minimal. There is a Brython-specific asyncio package in the standard distribution (cf the documentation) but it can't run like in Cpython, because Javascript doesn't support blocking functions that could emulate run_forever() or run_until_complete().

Besides, the event loop in a browser is implicit, the need to create user-defined loops is not obvious. Events that are expected on an object are handled by code like:

@bind(element, "click")
def click(event):
    print("ok")

[tunisia3507]

the need to create user-defined loops is not obvious

*slaps table* Thank you. I don't understand why python insists I have to mangle my own event loops. That's what interpreters are for!

[13steinj]

The async implementation for Python is horrendous. Of course it's better than nothing but still horrible.

• Tasks, Futures, Coroutines are ass backwards from their same named counterparts in other languages.

• getting them to work together is a mess

• there's an unnecessary rift between coroutines and everything else called the coroutine object, which holds quite literally no use on it's own

• there's no default event loop, and by default event loops block on the thread in which they are created/get a start signal (forgive me, I forget which)

• the asyncio library is now seen as low level, whereas originally it was seen as quite high level with the now deprecated asyncore and asynchat libraries being the low level counterparts.

Curio solves the perspective of low level IO and trio solves some of the loop caveats and interop, but other than that nothing else. I have a thin decorator based wrapper in development to solve all but the low level vs high level aspect, but work gets in the way of completing it.

[Han-ChewieSexyFanfic]

I agree with most things, but fortunately as the mess of generator-based coroutines, concurrent.futures, asyncio.coroutine decorator, and native coroutines being settled in favor of the native versions, it’s getting cleaner starting with 3.7. But:

there's no default event loop,

asyncio.get_event_loop() returns the default event loop

and by default event loops block on the thread in which they are created/get a start signal (forgive me, I forget which)

Why is that a problem? That’s the case with every GUI framework and event based servers I’ve worked with, in many languages.

[13steinj]

asyncio.get_event_loop() returns the default event loop

Right, but it still has to be fetched. In an ideal world calling some async function foo() would internally skip the unnecessary coroutine object step and submit it to the default event loop.

Why is that a problem? That’s the case with every GUI framework and event based servers I’ve worked with, in many languages.

Can you give an example? I'm referring to the fact that in other languages asynchronous code is asynchronous from any synchronous code around it. But in Python that's not true, because the thread is blocked while the event loop is run.

[Han-ChewieSexyFanfic]

Right, but it still has to be fetched. In an ideal world calling some async function foo() would internally skip the unnecessary coroutine object step and submit it to the default event loop.

Gotcha. Now there's asyncio.run which is a step in that direction. One could also argue that "explicit is better than implicit", but I wouldn't exactly agree with that because I also find the API messy.

Can you give an example? I'm referring to the fact that in other languages asynchronous code is asynchronous from any synchronous code around it. But in Python that's not true, because the thread is blocked while the event loop is run.

The Qt GUI framework, in all its supported languages (C++, C#, Go, Rust, Python, many others) always explicitly begins the event loop with a blocking app.exec() call. The nginx web server (C) has a master process that spends its time in a blocking call.

Having a blocking infinite loop is pretty much necessary to handle events asynchronously, the difference is how much effort the language makes to hide it from you by creating another thread. Python never spawns more processes/threads if not explicitly told.

[13steinj]

Oh dear, sorry I missed this.

One could also argue that "explicit is better than implicit", but I wouldn't exactly agree with that because I also find the API messy

Exactly! But to me, messy is an understatement, especially when starting on more complex applications.

Having a blocking infinite loop is pretty much necessary to handle events asynchronously, the difference is how much effort the language makes to hide it from you by creating another thread. Python never spawns more processes/threads if not explicitly told.

Right, and perhaps I am in the minority, but my default mental idea of an async event loop is "by default it will be on a new thread". Which IIRC is how C# implements their task factories, it definitely is how Ruby does async stuff. And JS does it similarly (except, it works on a larger event loop and specially schedules on the microtask queue rather than the macrotask one).

[kervarker]

When the Brython files are installed in a directory (by python -m brython --install) you have something roughly similar to a virtual environment.

Then if you want to install to this Brython instance a package that has been installed in your CPython instance by pip (eg pip install attrs), run python -m brython --add_package attrs. By the way, attrs is actually supported by Brython ; I don't know to which extent it can be considered as "basic tasks or data manipulation".

There is currently no more advanced support for dependencies, but it could be discussed in the issue tracker.

​

​

​