3 ms·

Good luck with compiling anything without having AST trees and proper parser infrastructure. In it's current state this thing won't fly.

by 1st1 14y ago

nostrademons 14y ago
They seem to have taken an interesting approach - it's a Javascript source file that translates the source for a restricted version of Python into equivalent Javascript constructs and then interprets that. A JS-based interpreter for Python-like text, basically. I don't think I would've implemented it this way, because: 1. It introduces the latency of having to download brython.js with every page load. 2. It supports only a subset of Python, whatever the implementor has gotten around to implementing. That's a pretty small subset so far - no list comprehensions, and I doubt he got the class & metaclass semantics right. 3. It'll run slowly because all the Python code is running through an interpreter, through a language that itself isn't blazingly fast. I would've done this as an on-the-server compiler from Python to JS, using Python's built-in ast module to parse the source directly, translate to an intermediate representation, and output optimized Javascript. That seems to be the approach PyJS takes, which seems to be a much more mature and well-designed project.
- cabalamat 14y ago
  > I doubt he got the class & metaclass semantics right. Brython doesn't implement classes at all, so you're right!
- asimjalis 14y ago
  The big advantage of Brython is that it has a very fast workflow, much like JavaScript. A server-side compiler approach would have a slower interactive workflow.
  - nostrademons 14y ago
    That's true, but you could probably get it to load & reparse the files off disk every request and serve the JS dynamically. If you've ever used Django or AppEngine, you just edit your templates and source files, you don't have to do a manual compile & load style every time you change things. There's no reason you couldn't set your PyJS serving URL to do the same. In terms of absolute CPU cycles burned, it's actually faster that way, since parsing happens in C using Python's built-in facilities, and the amount of JS shipped to the browser is less.

Good luck with compiling anything without having AST trees and proper parser infrastructure. In it's current state this thing won't fly.

by 1st1 14y ago

Good luck with compiling anything without having AST trees and proper parser infrastructure. In it's current state this thing won't fly.

nostrademons 14y ago

They seem to have taken an interesting approach - it's a Javascript source file that translates the source for a restricted version of Python into equivalent Javascript constructs and then interprets that. A JS-based interpreter for Python-like text, basically. I don't think I would've implemented it this way, because: 1. It introduces the latency of having to download brython.js with every page load. 2. It supports only a subset of Python, whatever the implementor has gotten around to implementing. That's a pretty small subset so far - no list comprehensions, and I doubt he got the class & metaclass semantics right. 3. It'll run slowly because all the Python code is running through an interpreter, through a language that itself isn't blazingly fast. I would've done this as an on-the-server compiler from Python to JS, using Python's built-in ast module to parse the source directly, translate to an intermediate representation, and output optimized Javascript. That seems to be the approach PyJS takes, which seems to be a much more mature and well-designed project.

cabalamat 14y ago
> I doubt he got the class & metaclass semantics right. Brython doesn't implement classes at all, so you're right!
asimjalis 14y ago
The big advantage of Brython is that it has a very fast workflow, much like JavaScript. A server-side compiler approach would have a slower interactive workflow.
- nostrademons 14y ago
  That's true, but you could probably get it to load & reparse the files off disk every request and serve the JS dynamically. If you've ever used Django or AppEngine, you just edit your templates and source files, you don't have to do a manual compile & load style every time you change things. There's no reason you couldn't set your PyJS serving URL to do the same. In terms of absolute CPU cycles burned, it's actually faster that way, since parsing happens in C using Python's built-in facilities, and the amount of JS shipped to the browser is less.