This uses Pyodide [0] under the hood [1], which is CPython compiled to WebAssembly. In all my tests of it, loading takes a long time ~5 seconds. Coldbrew [2], another distribution of CPython on Wasm, is another option with similar load times.
And Brython [3] is a completely different option without long load time: a Python interpreter implemented in JavaScript.
If load time is important, Brython is pretty nice. If feature completeness is important, Pyodide and Coldbrew are probably best.
There are actually quite a few Python-in-the-browser implementations, not just those two! A couple of years ago a colleague of mine wrote up a comparison, including Brython and Pyodide:
(We chose one of the Python-to-JS compilers, https://skulpt.org, for the Anvil web-app platform, because it's much lighter weight than this. It's a couple of hundred kb on the wire, and you can call to the server for any heavy lifting.)
okay thought it wasn't working because it seems to take a long time for the spinner to go away. but I'm very impressed with the todo.py! This is what frontend should be and in 5 years or so I wouldn't be surprised to see python taking over. If only the initial payload for the python runner was smaller and if only browsers started supporting webassembly/python stack out of the box!!!
from datetime import datetime as dt
from utils import add_class, remove_class
from js import console
tasks = []
# define the task template that will be use to render new templates to the page
task_template = Element("task-template").select('.task', from_content=True)
task_list = Element("list-tasks-container")
new_task_content = Element("new-task-content")
def add_task(*ags, **kws):
# create task
task_id = f"task-{len(tasks)}"
task = {"id": task_id, "content": new_task_content.element.value, "done": False, "created_at": dt.now()}
tasks.append(task)
# add the task element to the page as new node in the list by cloning
taskHtml = task_template.clone(task_id, to=task_list)
taskHtmlContent = taskHtml.select('p')
taskHtmlContent.element.innerText = task['content']
taskHtmlCheck = taskHtml.select('input')
task_list.element.appendChild(taskHtml.element)
def check_task(evt=None):
task['done'] = not task['done']
if task['done']:
add_class(taskHtmlContent, "line-through")
else:
remove_class(taskHtmlContent, "line-through")
new_task_content.clear()
taskHtmlCheck.element.onclick = check_task
def add_task_event(e):
if (e.key == "Enter"):
add_task()
Based on the responses, I assume this is a silly question, but why? Why would I want to run Python in HTML?
Does Python have some libraries that JS is missing? (I could think of AI/ML libs) The examples [1] seem so slow in my browser (Firefox on an Intel-based MBP) that they are borderline unusable for me (and some of them just straight out don't load within 60 seconds, like the Bokeh, at which point I give up).
If you already have a lot of domain logic in Python for your backend, that would make it easier to write a frontend living in the same codebase. (For example, imagine a framework for autogenerating forms for your Django models; this already exists server-side, but native client-side Python would give you more options. And if your framework owns both the client and server, it could autogenerate the API so you don’t even need to write one for happy-path usecases.)
If you are already using Python on the backend, not having to hire/train a completely different skill set/stack is appealing. Sure, the browser and CSS/HTML specialism is going to remain, but not having to split your team by JS vs <backend-language> would make it much easier for a team to collaborate and share work.
I think Python in the browser only has to be “almost as good” in a direct comparison for it to actually win out as the best choice organizationally for many teams.
It makes no sense to me also. One of the reasons Python so popular is due to it's interoperability with libraries written in C/C++, otherwise it's just super slow language. In the browser you can't access these fast libraries so you are left with a crap language with an even slower execution due to the interpreter VM written in JS
This isn't good for most web use cases but there are some major new use cases that it enables.
Pyodide is in Python documentation all over the place, for instance on https://numpy.org/
Python has many libraries that JS is missing. Particularly the scientific computing ecosystem has a lot of very well supported Python packages but fewer JavaScript packages. They also can benefit a lot from connection to a UI.
Two key use cases for this stuff are Python education and scientific computing. Students have a hard time installing Python locally. Generally scientists want to share their results broadly, but they probably did their analysis in Python.
I think it's primarily meant as a learning tool. Here's the TL;DR from their GitHub.[1]
PyScript is a Pythonic alternative to Scratch, JSFiddle or other "easy to use" programming frameworks, making the web a friendly, hackable, place where anyone can author interesting and interactive applications.
Regarding the size of the download, I know there is ongoing work in the Pyodide project to create a much smaller python runtime that will help tremendously. Also, the script will be cached once you download it once.
EDIT: Also, you don't need NPM or anything locally to run these
But some other low hanging fruit include unvendoring the special encodings for Asian languages (hopefully everyone uses utf8), the decimal library, and the xml library which are all quite large and only occasionally used.
I really really like this, but 4 MB zipped is a bit of a hard sell :/ I've had a need to deploy small ad-hoc HTML tools at work, though, and my Python is much better than my JS, so maybe it's worth it.
Local intranet / work tools would actually be a good use case for this as the load is small (tens, hundreds, maybe thousands of employees at absolute most) and mostly the same repeat users so browser caching would make it snappy for them on future visits.
A public marketing page where it's the random internet of totally new/anonymous users who want to instantly find out info about your product would be the worst use case for this IMHO.
For one of the examples, I saw it coming down with pyscript.js - 1.1 MB, pyodide.asm data + wasm of 16 MB, and each python package as a separate wheel download (cool!), matplotlib of 6MB :)
I've learned to accept my larger snake overlord. I know a lot of people work very hard on the anaconda project. It is a fork of what I consider to be actually pythonic. I am pretty sure there are a lot of big money actors working in the space to "Embrace, Extinguish, Destroy" what I know to be Python via the Anaconda project. This is really interesting stuff and is the first evidence I've seen other than money and some very specific political stuff that shows me they might do something worth something. Congrats! I will use this! I mourn what's lost, but embrace the future.
Is this similar at all to the old pyjs/pyjamas project? I had some fun playing with that but there was no way I would have ever actually made anything serious with it.
That was a very cool project, though I believe they aren't really related, even though they seem similar. Pyjs/Pyjamas was a more of a Python to JavaScript transpiler.
This is the actual CPython runtime with full standard library and many of the Python mathematical and plotting libraries compiled to WASM, running in the browser. It can also be included with other HTML and JavaScript on a web page just by wrapping the Python in a tag.
wasm supports any language that compiles to wasm (or has its interpreter compiled to wasm). It's a bit like asking if "x86 assembly supports other languages"-- it supports whatever targets it!
Pyodide is really cool, we got a Python library we were working on working in JS in the browser with it, including Pandas iirc, without too much trouble (though getting http requests working required a little hackery).
Python is the worst language to script anything inside a markup language that does not need to be structured like Python (HTML). So yeah, a good experiment, but unfortunately it is doomed to fail.
[+] [-] eatonphil|3 years ago|reply
And Brython [3] is a completely different option without long load time: a Python interpreter implemented in JavaScript.
If load time is important, Brython is pretty nice. If feature completeness is important, Pyodide and Coldbrew are probably best.
[0] https://github.com/pyscript/pyscript/blob/main/pyscriptjs/sr...
[1] https://github.com/pyodide/pyodide
[2] https://github.com/plasticityai/coldbrew
[3] https://github.com/brython-dev/brython
[+] [-] meredydd|3 years ago|reply
https://anvil.works/blog/python-in-the-browser-talk
(We chose one of the Python-to-JS compilers, https://skulpt.org, for the Anvil web-app platform, because it's much lighter weight than this. It's a couple of hundred kb on the wire, and you can call to the server for any heavy lifting.)
[+] [-] worewood|3 years ago|reply
[+] [-] nhumrich|3 years ago|reply
[+] [-] stavros|3 years ago|reply
[+] [-] manjana|3 years ago|reply
[+] [-] closed|3 years ago|reply
https://pyscript.net/examples/
(This was presented today as a pycon keynote talk!)
[+] [-] tomatowurst|3 years ago|reply
[+] [-] edmcnulty101|3 years ago|reply
[+] [-] asimjalis|3 years ago|reply
[+] [-] erwincoumans|3 years ago|reply
[+] [-] BossingAround|3 years ago|reply
Does Python have some libraries that JS is missing? (I could think of AI/ML libs) The examples [1] seem so slow in my browser (Firefox on an Intel-based MBP) that they are borderline unusable for me (and some of them just straight out don't load within 60 seconds, like the Bokeh, at which point I give up).
[1] https://pyscript.net/examples
[+] [-] theptip|3 years ago|reply
If you are already using Python on the backend, not having to hire/train a completely different skill set/stack is appealing. Sure, the browser and CSS/HTML specialism is going to remain, but not having to split your team by JS vs <backend-language> would make it much easier for a team to collaborate and share work.
I think Python in the browser only has to be “almost as good” in a direct comparison for it to actually win out as the best choice organizationally for many teams.
[+] [-] firechickenbird|3 years ago|reply
[+] [-] hoodchatham|3 years ago|reply
This isn't good for most web use cases but there are some major new use cases that it enables.
Pyodide is in Python documentation all over the place, for instance on https://numpy.org/
Python has many libraries that JS is missing. Particularly the scientific computing ecosystem has a lot of very well supported Python packages but fewer JavaScript packages. They also can benefit a lot from connection to a UI.
Two key use cases for this stuff are Python education and scientific computing. Students have a hard time installing Python locally. Generally scientists want to share their results broadly, but they probably did their analysis in Python.
Here's another example of a good use case: https://www.socialfinance.org.uk/blogs/analysing-sensitive-d...
[+] [-] lstmemery|3 years ago|reply
PyScript is a Pythonic alternative to Scratch, JSFiddle or other "easy to use" programming frameworks, making the web a friendly, hackable, place where anyone can author interesting and interactive applications.
https://github.com/pyscript/pyscript
[+] [-] grej|3 years ago|reply
Regarding the size of the download, I know there is ongoing work in the Pyodide project to create a much smaller python runtime that will help tremendously. Also, the script will be cached once you download it once.
EDIT: Also, you don't need NPM or anything locally to run these
[+] [-] hoodchatham|3 years ago|reply
But some other low hanging fruit include unvendoring the special encodings for Asian languages (hopefully everyone uses utf8), the decimal library, and the xml library which are all quite large and only occasionally used.
[+] [-] asimjalis|3 years ago|reply
https://github.com/pyscript/pyscript
Would be nice if there was a demo on the page that didn’t require installing NPM and other stuff on my machine.
[+] [-] obert|3 years ago|reply
[+] [-] stavros|3 years ago|reply
[+] [-] qbasic_forever|3 years ago|reply
A public marketing page where it's the random internet of totally new/anonymous users who want to instantly find out info about your product would be the worst use case for this IMHO.
[+] [-] kzrdude|3 years ago|reply
[+] [-] hoten|3 years ago|reply
Any reason to use a custom element `py-script` vs a script tag with custom type?
[+] [-] VectorLock|3 years ago|reply
[+] [-] stuntkite|3 years ago|reply
[+] [-] patrick91|3 years ago|reply
[+] [-] als0|3 years ago|reply
[+] [-] VWWHFSfQ|3 years ago|reply
[+] [-] grej|3 years ago|reply
This is the actual CPython runtime with full standard library and many of the Python mathematical and plotting libraries compiled to WASM, running in the browser. It can also be included with other HTML and JavaScript on a web page just by wrapping the Python in a tag.
[+] [-] prpl|3 years ago|reply
[+] [-] 999900000999|3 years ago|reply
Of course it would be better if Chrome shipped with Python support, but this is a good effort. Does Wasm generally support other languages ?
[+] [-] kevinmgranger|3 years ago|reply
[+] [-] nathanganser|3 years ago|reply
[+] [-] ericd|3 years ago|reply
[+] [-] _pdp_|3 years ago|reply
[+] [-] ltdanimal|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] alanh|3 years ago|reply
[+] [-] cutler|3 years ago|reply
[+] [-] hoten|3 years ago|reply
[+] [-] ak391|3 years ago|reply