4 ms·
Such an initiative would involve reimplementing/proxying the entire set of browser APIs to Python: not only would that be a huge undertaking maintenance-wise fo
by lucideer 4y ago
Such an initiative would involve reimplementing/proxying the entire set of browser APIs to Python: not only would that be a huge undertaking maintenance-wise for the developer of that project, but also, for any Python dev wanting to write userscripts, the learning curve for the new Python API wrappers would be much much higher than just learning JS.
If you like CLIP, just writing CLIP.js would be much much easier (and have more applications).
> x.isnumeric() and 10000 > int(x) > 5000
isFinite(x) && 10000 > x && x > 5000
Learning another C-like scripting language when you already know one is really not very difficult (certainly hella easier than learning a new set of platform APIs).
- pizza 4y agoI think that is pretty much the goal of pyscript: https://github.com/pyscript/pyscript/blob/main/docs/tutorials/getting-started.md https://github.com/pyscript/pyscript/blob/main/docs/tutorial... Bidirectional python<->javascript communication, + the entirety of the python ecosystem
- bryanrasmussen 4y agoreimplementing/proxying the entire set of browser APIs would mean such things as DOM, the CSSOM, the browser specific JavaScript APIs, the SVGOM, the accessibility tree and probably a few other things I'm not thinking of at the moment, so a lot more than just JavaScript being understandable by Python. However I suppose it could be done with Ghost.py or similar library?
- lucideer 4y agoThat project looks very cool - definitely a good starting point if you want to achieve this as a proof-of-concept at least, as that project looks very advanced & mature. I didn't say it wasn't possible. It's just going to be inefficient, high-maintenance and have a steep learning curve. > + the entirety of the python ecosystem Worth noting: you would only be able to use "self-contained" or "pure" libraries from the python ecosystem; any Python-only APIs in use for IO won't translate to a browser environment (or will need explicit re-implementation to map them to something different). It's essentially about learning the difference between IO API surface (DOM/W3C web APIs -vs- Python File IO/networking/etc.) and language syntax (PEP vs ECMA). Syntax translation is the (relatively) easy part - API mapping is a massive moving target, as well as an added learning curve for programmers using your system.