5 ms·

Here's a free project idea for someone. I really want to implement but probably don't have the time to, so I'd like someone else to make it: userscripts +

by pizza 4y ago

Here's a free project idea for someone. I really want to implement but probably don't have the time to, so I'd like someone else to make it: userscripts + pyscript => script any web page using python this is a bit of a convoluted example but e.g. imagine you want to be able to grep web pages visually, boom just write a userscript that uses CLIP to find the DOM element you are looking for, whether that's visually or with just text. or if you want semantic text search, or even something simpler like find all the text matching x.isnumeric() and 10000 > int(x) > 5000 or imagine reading a blog post and you want to annotate interactively/play a bit with the ideas presented. imagine you could insert some jupyter cells inlined between the article paragraphs, with full matplotlib plots and everything, then save and export the annotated article to be shared with others

yewenjie 4y ago
Does JS really have a higher entry barrier than Python?
- pizza 4y ago
  It's less so about lowering the barrier of entry and more about - vastly multiplying the number of available libraries at one's disposal to tweak the browsing experience - less wheel reinvention and writing less code
  - chrismorgan 4y ago
    Uh… you know there are rather a lot of libraries for JavaScript too? For general-purpose computing, and even more so for web stuff? It sounds to me like the body of what you’re wanting is the ability to execute code outside the browser. That would, of course, be rather hazardous for security, and there’s a reason why user script managers don’t expose such a thing. But it’s not actually all that hard to do, especially if you’re willing to take the form of running an HTTP server on localhost and treat that as an FFI boundary. In case you thought otherwise: PyScript will not run anything like CLIP, which makes liberal use of non-Python code. You could conceivably compile something like CLIP to WebAssembly, but it would certainly be slower, probably vastly slower; or perhaps JavaScript + WebGPU would be a better target.
    - alanbernstein 4y ago
      Uh... Is it so hard to accept that people like using different languages for different things? I understand there are challenges that may make this idea infeasible or just not worth the maintenance effort. But if it existed, I would definitely try it. I like python. I don't like JavaScript as much. I have hundreds of small python projects from which I can draw experience and code samples. If I could use those directly in a browser, I could do some neat stuff. Or, I could re-implement them in the JavaScript ecosystem. But I have never done that. Because it's not fun for me.
      - chrismorgan 4y ago
        My point is that, generally speaking, what pizza is asking for doesn’t practically increase the libraries available (I would expect that JavaScript already has equivalents for the vast majority of the applicable pure Python libraries—and libraries that aren’t pure Python won’t work), and doesn’t solve as much as you’d hope in the way of wheel reinvention and writing less code (in fact, I’d categorise the entire effort as wheel reinvention and writing more code, though I acknowledge the library versus end user distinction in this regard). Your second paragraph reinforces my very point; pizza was saying it’s not so much about lowering a barrier of entry, yet that’s the majority of what you’re wanting it for.
- traverseda 4y ago
  If you need libraries or packaging, yes. Gulp, browserify, babel, etc. There are a lot of pre-processors, any number of which may end up being necessary to use certain libraries. That can be pretty complicated.
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 ago
  I 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 ago
    reimplementing/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 ago
    That 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.

by pizza 4y ago

yewenjie 4y ago

Does JS really have a higher entry barrier than Python?

pizza 4y ago
It's less so about lowering the barrier of entry and more about - vastly multiplying the number of available libraries at one's disposal to tweak the browsing experience - less wheel reinvention and writing less code
- chrismorgan 4y ago
  Uh… you know there are rather a lot of libraries for JavaScript too? For general-purpose computing, and even more so for web stuff? It sounds to me like the body of what you’re wanting is the ability to execute code outside the browser. That would, of course, be rather hazardous for security, and there’s a reason why user script managers don’t expose such a thing. But it’s not actually all that hard to do, especially if you’re willing to take the form of running an HTTP server on localhost and treat that as an FFI boundary. In case you thought otherwise: PyScript will not run anything like CLIP, which makes liberal use of non-Python code. You could conceivably compile something like CLIP to WebAssembly, but it would certainly be slower, probably vastly slower; or perhaps JavaScript + WebGPU would be a better target.
  - alanbernstein 4y ago
    Uh... Is it so hard to accept that people like using different languages for different things? I understand there are challenges that may make this idea infeasible or just not worth the maintenance effort. But if it existed, I would definitely try it. I like python. I don't like JavaScript as much. I have hundreds of small python projects from which I can draw experience and code samples. If I could use those directly in a browser, I could do some neat stuff. Or, I could re-implement them in the JavaScript ecosystem. But I have never done that. Because it's not fun for me.
    - chrismorgan 4y ago
      My point is that, generally speaking, what pizza is asking for doesn’t practically increase the libraries available (I would expect that JavaScript already has equivalents for the vast majority of the applicable pure Python libraries—and libraries that aren’t pure Python won’t work), and doesn’t solve as much as you’d hope in the way of wheel reinvention and writing less code (in fact, I’d categorise the entire effort as wheel reinvention and writing more code, though I acknowledge the library versus end user distinction in this regard). Your second paragraph reinforces my very point; pizza was saying it’s not so much about lowering a barrier of entry, yet that’s the majority of what you’re wanting it for.
traverseda 4y ago
If you need libraries or packaging, yes. Gulp, browserify, babel, etc. There are a lot of pre-processors, any number of which may end up being necessary to use certain libraries. That can be pretty complicated.

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 ago
I 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 ago
  reimplementing/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 ago
  That 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.