6 ms·

Brython - Python to Javascript translator

270 points by toni 14y ago

awolf 14y ago
I think compiler is the wrong way to describe this. A computer program that translates between two different high level languages is typically called a language translator.
- toni 14y ago
  Thanks, I edited the title.
- tantalor 14y ago
  Not anymore, see Closure Compiler, CoffeeScript compiler, TypeScript compiler, dart2js compiler, and tons more: https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS https://github.com/jashkenas/coffee-script/wiki/List-of-lang... It's pretty common now to call these "compilers".
  - nostrademons 14y ago
    Yeah, a compiler is anything that translates from one programming language to another. The definition of a "high level language" is muddy these days - is C a high-level language? It's a compiler target for Scheme, Haskell, Goo, Python, and many other programming languages these days. It's also a source language for gcc, Clang, and numerous other C compilers.
- ender7 14y ago
  The technical term is "transpiler". However, people tend to use "compiler" interchangeably without much confusion.
- bitcrusher 14y ago
  Wouldn't "preprocessor" be a more accurate description?
  - ufo 14y ago
    No. A preprocessor usually translates into the same or a very similar language.
mahmoudimus 14y ago
Wow! This is so awesome. This has been tried before, but I don't remember why it never succeeded. I wonder if this can get the appropriate community to make it a decent alternative compared with TypeScript and CoffeeScript - or maybe I'm missing something here?
- TazeTSchnitzel 14y ago
  Once brython gets some key missing Python features (classes, list comprehensions, lambdas), and some libraries for it, I think it has huge potential.
  - nnq 14y ago
    Indeed! Right now Coffee script offers more expressive power than this. So they should add these features fast if they want this to succeed in the highly competitive world of compile-to-js languages!
- sumukh1 14y ago
  We made a similar compiler with the same goal of supporting text/python but it only compiled python it down into javascript. We could manipulate images from the webcam and make calls to jQuery and through python. In the end, it was hard to replicate 100% of the usefulness of JS through python and convert python's cool features into JS.
- VexXtreme 14y ago
  > This has been tried before, but I don't remember why it never succeeded. Because as cool as the project is (from a scientific perspective), ultimately it will end up not being used by anyone. Most developers and companies who build production grade software for a living stick to true and tried technologies, vs. fancy esoteric stuff like this. Don't get me wrong, I am not knocking this project and the person who created it, I am just stating the obvious reason why things like this rarely take off.
- eddieplan9 14y ago
  There is no shortage of compile-to-JS languages. For a non-comprehensive list, see https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS https://github.com/jashkenas/coffee-script/wiki/List-of-lang... For many of the offerings in the list, the problem, IMHO, is the lack of a complete story. If you base it on an existing language - in this case, Python - you would expect a full implementation of the language, or at least a good portion of the core language features. The benefits of an existing language are often familiarity and the potential to reuse existing code. With partial implementation, you can hardly gain these. And the downside of extra abstraction quickly outweighs any superficial perception of familiarity. If you create a new language, you have to strike a good balance between language features and interoperability. You need to bring enough new things to the table to make it worthwhile to learn, adopt and support it, and yet you can't overstate the importance of a good interoperability story unless you can afford to completely ignore the JavaScript ecosystem. See DART.
DanielRibeiro 14y ago
Repl.it has supported python on the browser for a while: http://repl.it/ http://repl.it/ (an an interpreter, not as a translator, though). It also supports ruby, scheme, lua and others[1] What made it impractical was the slowness. Emscripten seems to work fine for clang[2], not so much for interpreted languages. Maybe the translator path can solve this issue. [1] http://repl.it/#:languages http://repl.it/#:languages [2] https://developer.mozilla.org/en-US/demos/detail/bananabread https://developer.mozilla.org/en-US/demos/detail/bananabread
- azakai 14y ago
  > What made it impractical was the slowness. Much of the slowness was because emscripten was immature at the time that repl.it worked on their port. If someone built python with current-day emscripten it should be much faster. There is a better way, though. We could compile PyPy's generated C implementation and add a JIT to JS to that. That would be the best way to get fast python into the browser. If anyone is interested to hack on that let me know, I would assist from the emscripten side. Note though that this would only give throughput speed, not startup speed. For startup speed, a method like pyjamas or bython will do better - at the cost of not fully supporting the python language, of course.
- jimhefferon 14y ago
  > What made it impractical was the slowness. Although, speed is way less important when the code is running on lots of browsers out there, compared with running lots of instances on your server.
danjaouen 14y ago
While this is an awesome effort, I don't see myself using this without list comprehensions/generators/itertools/etc.
javis 14y ago
This is amazing. I hope one day we'll have the option to use Python as a scripting language for the web. I've messed around with Python turned on in Chrome, and I think it'd make a great alternative to JavaScript.
T-A 14y ago
Also worthy of mention in this context: http://pyjaco.org/about http://pyjaco.org/about and http://pyjs.org/ http://pyjs.org/
- lost-theory 14y ago
  And http://www.skulpt.org/ http://www.skulpt.org/
- daemon13 14y ago
  >> Also worthy of mention in this context: http://pyjaco.org/about http://pyjaco.org/about and http://pyjs.org/ http://pyjs.org/ Based on your personal experience - with which one to start?
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.
dbaupp 14y ago
This looks really nice! It seems like the other side of the Python-in-the-browser coin to Empythoned (https://github.com/replit/empythoned https://github.com/replit/empythoned) used by repl.it (http://repl.it/ http://repl.it/). (Ignore this...)The mime-type is wrong though, there isn't an authoritative mime-type for Python, so it should use a private subtype like text/x-python or application/x-python.
- dalke 14y ago
  RFC 6648: Deprecating the "X-" Prefix and Similar Constructs in Application Protocols """Historically, designers and implementers of application protocols have often distinguished between standardized and unstandardized parameters by prefixing the names of unstandardized parameters with the string "X-" or similar constructs. In practice, that convention causes more problems than it solves. Therefore, this document deprecates the convention for newly defined parameters with textual (as opposed to numerical) names in application protocols. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community."""
  - dbaupp 14y ago
    Oh, neat. Thanks for the pointer!
GauntletWizard 14y ago
This is long overdue - The DOM is a great model of objects, but javascript is not the way forward. For all the admittedly great work that has been done to improve it, it's still a mess of a language. Native support of Python would be my dream (I don't see why there's not 3-4 competing languages in the browser; though the complexity of such is a decent argument against), but this solution seems to be a great stopgap, as well as compatible with future in-browser python implementations.
ct 14y ago
Python needs to be natively supported as a scripting lang in browsers. Google, MS, Firefox - make it so!
- trothamel 14y ago
  As much as I like Python, I don't think this is the right approach. What browsers need to do is to have a machine-level bytecode, so that they can download whatever interpreters are needed to run the scripting code the page uses. Then pages can be written in whatever language the developer feels is best. This is the real potential of something like Native Client - although it doesn't look like that potential will be achieved any time soon.
  - Niten 14y ago
    As much as I don't like Microsoft, I actually think the .NET CLR would be an excellent choice for such a runtime. NaCl not so much; target architecture-dependent compiled code is a major downside.
    - tlrobinson 14y ago
      There's PNaCl: http://www.chromium.org/nativeclient/pnacl/building-and-testing-portable-native-client http://www.chromium.org/nativeclient/pnacl/building-and-test...
    - greggman 14y ago
      What about pnacl? http://www.chromium.org/nativeclient/pnacl/building-and-testing-portable-native-client http://www.chromium.org/nativeclient/pnacl/building-and-test...
      - Niten 14y ago
        I had no idea about that, thanks
  - cbhl 14y ago
    Pages downloading and executing things just reminds me of ActiveX from the late 90s. I think South Korea still relies on the technology for their home-grown version of SSL.
halayli 14y ago
No support for python classes?
deleted 14y ago
[deleted]
asimjalis 14y ago
Very nice. Can this approach be generalized to embed Clojure, Haskell, and other languages into the browser? I love the pervasiveness of JavaScript but I dislike writing it. This is a very good tradeoff.
- spacemanaki 14y ago
  There are already implementations of Clojure and Haskell that target JavaScript, but I'm not sure if that's what you meant. I don't know if there are any implementations that target JS using this specific approach but I don't think it's one to necessarily emulate; as nostrademons points out it is interesting, but not really optimal. https://github.com/clojure/clojurescript https://github.com/clojure/clojurescript http://www.haskell.org/haskellwiki/The_JavaScript_Problem http://www.haskell.org/haskellwiki/The_JavaScript_Problem https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS https://github.com/jashkenas/coffee-script/wiki/List-of-lang...
  - asimjalis 14y ago
    These are all neat, but they require some effort to bootstrap. The neat thing about Brython is that you can start writing Python immediately. I’ve played with ClojureScript and it takes a while to get the QuickStart to work. I think Brython is cool, not from an efficiency or machine-performance point of view, but from a human point of view. It makes it easy to start hacking. The barrier to entry is non-existent.
tnuc 14y ago
Looks interesting. Certainly a step in the right direction. Are there any specs as to the speed of using this? Javascript can be a bit slow on most days, does Brython make it worse?
jachwe 14y ago
Looks really cool. And i love Python. However, I think the Python Syntax will make it hard to minify the code, which is probably not that important anyway when not in production. But for production usage it would be cool to have a real compiler instead of an interpreter. But yeah. Cool stuff.
- limpangel 14y ago
  I guess you could just gzip your python code without minification, here's a little bench: https://github.com/jch/gzip_vs_minify https://github.com/jch/gzip_vs_minify
madhadron 14y ago
If you want to do this kind of thing on the server side, Python provides enough introspection to turn functions in a live Python image into JavaScript. Here's a minimal example I tossed together a while back: https://gist.github.com/50d706081074aed8fcf6 https://gist.github.com/50d706081074aed8fcf6 I have a bunch of notes somewhere on translating a big hunk of the basic language, including how to generate continuation passing style code in JavaScript from less ghastly Python. The difficulty is providing all the class semantics and the standard library.
- ville 14y ago
  I like the simplicity of that gist. Very cool hack. However if I was to implement a Python to JavaScript compiler, would there be some benefits in transforming the Python AST into a JS AST first? There are existing code generators such as escodegen that transform that AST to JavaScript code.
leetrout 14y ago
As a lover of Python myself, this is awesome. However, as others are noting things that are missing that we pythonistas can't live without (generators, classes, etc)- I feel it is worth a reminder that Javascript 6 (Harmony) is going to have a lot of these built in. Brendan's slides have a great overview of what's to come (and makes me hope writing JS outside of CoffeeScript will become more bearable since I'm so spoiled by Python: http://brendaneich.github.com/Strange-Loop-2012/ http://brendaneich.github.com/Strange-Loop-2012/
alecthomas 14y ago
Once upon a time I wrote Oink, which generates JS from Python on the server: https://github.com/alecthomas/oink https://github.com/alecthomas/oink It has support for many of the Python niceties: classes, list comprehensions, positional arguments, and so on. Interesting experiment, but I ended up thinking that Python is not the best language for the browser.
- slurgfest 14y ago
  Because its syntax can't work with the DOM, or what?
deleted 14y ago
[deleted]
fijal 14y ago
I'm genuinely shocked that this made it to the top of hackernews. I would expect better. While the idea of having the Python interpreter in the browser is very likely better than having a compiler Python -> JS (if we care about Python), the implementation here is both half assed and really bad. It takes quite a bit of effort to create a python interpreter that can be called python. This is nowhere near there. On top of it double-interpretation in dynamic languages is very slow and I doubt someone is willing to pay that price here. A good example of low quality is here: http://code.google.com/p/brython/source/browse/trunk/py_classes.js#140 http://code.google.com/p/brython/source/browse/trunk/py_clas... this is both incorrect (exceptions are propagated, http://paste.pound-python.org/show/28457/ http://paste.pound-python.org/show/28457/) and has wrong complexity. It's not even a dict at all!
- why-el 14y ago
  I will be more shocked if I discovered that people dive this deep into code before upvoting, because it is generally not the case. If you think of it, we would have missed your valuable input if people didnt upvote this for you to see. :)
- tinco 14y ago
  It is an indication that we just want to get a python for the web really bad. If someone makes a good looking website for his project it kind of gives the impression that he is seriously going for it, perhaps it is not good now, but maybe it will become a serious contender later.
- daemon13 14y ago
  All people are different... There are many OPs that assert that JS syntax/lang are beautiful once you get handle of it, and may be it is... However, there may be enough people like myself for whom the JS syntax/lang just do not fit into the brain. Since at my last job of CFO of $200+m pharma country org I have architected multidimensional db for an OLAP cube for SAP Business Objects, I do not think that I am that dumb. But this JS stuff just does not fit in. Also, I do value my time. So although I could persist in learning JS, as a general rule when things do not flow - the learning time multiplies. I do not have time. Hence, personally I would love to be able to write/maintain code in Python [even subset of Python would be fine], knowing that it cleanly compiles to JS. It will be then my choice whether I want it client-side or server-side [smth like what css pre-processors SASS/Less are doing].
TommyDANGerous 14y ago
What? This is insane. Python replacing javascript, insane as in that is super cool. If I could do the exact same things I can do in javascript/query but with python syntax, that would be magical.
kelvin0 14y ago
OK, how about : 1) getting Python ==> LLVM bytecode 2) then using emscripten (https://github.com/kripken/emscripten/wiki https://github.com/kripken/emscripten/wiki) to run LLVM in browser? An option to perform the first step seems to be : http://code.google.com/p/py2llvm/ http://code.google.com/p/py2llvm/ Or 'simply' getting CPython ported on emscripten? Any opinions on this suggestion?
- muyuu 14y ago
  I've seen that done already, but the resulting Python interpreter has no visibility of the DOM or access to the browser. You have basically a Python console, which is quite useless if what you want is to substitute Javascript.
  - zever 14y ago
    Just for reference, there's an example of CPython compiled to JavaScript using Emscripten running in the browser at http://syntensity.com/static/python.html http://syntensity.com/static/python.html

270 points by toni 14y ago

awolf 14y ago

I think compiler is the wrong way to describe this. A computer program that translates between two different high level languages is typically called a language translator.

toni 14y ago
Thanks, I edited the title.
tantalor 14y ago
Not anymore, see Closure Compiler, CoffeeScript compiler, TypeScript compiler, dart2js compiler, and tons more: https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS https://github.com/jashkenas/coffee-script/wiki/List-of-lang... It's pretty common now to call these "compilers".
- nostrademons 14y ago
  Yeah, a compiler is anything that translates from one programming language to another. The definition of a "high level language" is muddy these days - is C a high-level language? It's a compiler target for Scheme, Haskell, Goo, Python, and many other programming languages these days. It's also a source language for gcc, Clang, and numerous other C compilers.
ender7 14y ago
The technical term is "transpiler". However, people tend to use "compiler" interchangeably without much confusion.
bitcrusher 14y ago
Wouldn't "preprocessor" be a more accurate description?
- ufo 14y ago
  No. A preprocessor usually translates into the same or a very similar language.

mahmoudimus 14y ago

Wow! This is so awesome. This has been tried before, but I don't remember why it never succeeded. I wonder if this can get the appropriate community to make it a decent alternative compared with TypeScript and CoffeeScript - or maybe I'm missing something here?

TazeTSchnitzel 14y ago
Once brython gets some key missing Python features (classes, list comprehensions, lambdas), and some libraries for it, I think it has huge potential.
- nnq 14y ago
  Indeed! Right now Coffee script offers more expressive power than this. So they should add these features fast if they want this to succeed in the highly competitive world of compile-to-js languages!
sumukh1 14y ago
We made a similar compiler with the same goal of supporting text/python but it only compiled python it down into javascript. We could manipulate images from the webcam and make calls to jQuery and through python. In the end, it was hard to replicate 100% of the usefulness of JS through python and convert python's cool features into JS.
VexXtreme 14y ago
> This has been tried before, but I don't remember why it never succeeded. Because as cool as the project is (from a scientific perspective), ultimately it will end up not being used by anyone. Most developers and companies who build production grade software for a living stick to true and tried technologies, vs. fancy esoteric stuff like this. Don't get me wrong, I am not knocking this project and the person who created it, I am just stating the obvious reason why things like this rarely take off.
eddieplan9 14y ago
There is no shortage of compile-to-JS languages. For a non-comprehensive list, see https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS https://github.com/jashkenas/coffee-script/wiki/List-of-lang... For many of the offerings in the list, the problem, IMHO, is the lack of a complete story. If you base it on an existing language - in this case, Python - you would expect a full implementation of the language, or at least a good portion of the core language features. The benefits of an existing language are often familiarity and the potential to reuse existing code. With partial implementation, you can hardly gain these. And the downside of extra abstraction quickly outweighs any superficial perception of familiarity. If you create a new language, you have to strike a good balance between language features and interoperability. You need to bring enough new things to the table to make it worthwhile to learn, adopt and support it, and yet you can't overstate the importance of a good interoperability story unless you can afford to completely ignore the JavaScript ecosystem. See DART.

DanielRibeiro 14y ago

Repl.it has supported python on the browser for a while: http://repl.it/ http://repl.it/ (an an interpreter, not as a translator, though). It also supports ruby, scheme, lua and others[1] What made it impractical was the slowness. Emscripten seems to work fine for clang[2], not so much for interpreted languages. Maybe the translator path can solve this issue. [1] http://repl.it/#:languages http://repl.it/#:languages [2] https://developer.mozilla.org/en-US/demos/detail/bananabread https://developer.mozilla.org/en-US/demos/detail/bananabread

azakai 14y ago
> What made it impractical was the slowness. Much of the slowness was because emscripten was immature at the time that repl.it worked on their port. If someone built python with current-day emscripten it should be much faster. There is a better way, though. We could compile PyPy's generated C implementation and add a JIT to JS to that. That would be the best way to get fast python into the browser. If anyone is interested to hack on that let me know, I would assist from the emscripten side. Note though that this would only give throughput speed, not startup speed. For startup speed, a method like pyjamas or bython will do better - at the cost of not fully supporting the python language, of course.
jimhefferon 14y ago
> What made it impractical was the slowness. Although, speed is way less important when the code is running on lots of browsers out there, compared with running lots of instances on your server.

danjaouen 14y ago

While this is an awesome effort, I don't see myself using this without list comprehensions/generators/itertools/etc.

javis 14y ago

This is amazing. I hope one day we'll have the option to use Python as a scripting language for the web. I've messed around with Python turned on in Chrome, and I think it'd make a great alternative to JavaScript.

T-A 14y ago

Also worthy of mention in this context: http://pyjaco.org/about http://pyjaco.org/about and http://pyjs.org/ http://pyjs.org/

lost-theory 14y ago
And http://www.skulpt.org/ http://www.skulpt.org/
daemon13 14y ago
>> Also worthy of mention in this context: http://pyjaco.org/about http://pyjaco.org/about and http://pyjs.org/ http://pyjs.org/ Based on your personal experience - with which one to start?

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.

dbaupp 14y ago

This looks really nice! It seems like the other side of the Python-in-the-browser coin to Empythoned (https://github.com/replit/empythoned https://github.com/replit/empythoned) used by repl.it (http://repl.it/ http://repl.it/). (Ignore this...)The mime-type is wrong though, there isn't an authoritative mime-type for Python, so it should use a private subtype like text/x-python or application/x-python.

dalke 14y ago
RFC 6648: Deprecating the "X-" Prefix and Similar Constructs in Application Protocols """Historically, designers and implementers of application protocols have often distinguished between standardized and unstandardized parameters by prefixing the names of unstandardized parameters with the string "X-" or similar constructs. In practice, that convention causes more problems than it solves. Therefore, this document deprecates the convention for newly defined parameters with textual (as opposed to numerical) names in application protocols. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community."""
- dbaupp 14y ago
  Oh, neat. Thanks for the pointer!

GauntletWizard 14y ago

This is long overdue - The DOM is a great model of objects, but javascript is not the way forward. For all the admittedly great work that has been done to improve it, it's still a mess of a language. Native support of Python would be my dream (I don't see why there's not 3-4 competing languages in the browser; though the complexity of such is a decent argument against), but this solution seems to be a great stopgap, as well as compatible with future in-browser python implementations.

ct 14y ago

Python needs to be natively supported as a scripting lang in browsers. Google, MS, Firefox - make it so!

trothamel 14y ago
As much as I like Python, I don't think this is the right approach. What browsers need to do is to have a machine-level bytecode, so that they can download whatever interpreters are needed to run the scripting code the page uses. Then pages can be written in whatever language the developer feels is best. This is the real potential of something like Native Client - although it doesn't look like that potential will be achieved any time soon.
- Niten 14y ago
  As much as I don't like Microsoft, I actually think the .NET CLR would be an excellent choice for such a runtime. NaCl not so much; target architecture-dependent compiled code is a major downside.
  - tlrobinson 14y ago
    There's PNaCl: http://www.chromium.org/nativeclient/pnacl/building-and-testing-portable-native-client http://www.chromium.org/nativeclient/pnacl/building-and-test...
  - greggman 14y ago
    What about pnacl? http://www.chromium.org/nativeclient/pnacl/building-and-testing-portable-native-client http://www.chromium.org/nativeclient/pnacl/building-and-test...
    - Niten 14y ago
      I had no idea about that, thanks
- cbhl 14y ago
  Pages downloading and executing things just reminds me of ActiveX from the late 90s. I think South Korea still relies on the technology for their home-grown version of SSL.

halayli 14y ago

No support for python classes?

deleted 14y ago

[deleted]

asimjalis 14y ago

Very nice. Can this approach be generalized to embed Clojure, Haskell, and other languages into the browser? I love the pervasiveness of JavaScript but I dislike writing it. This is a very good tradeoff.

spacemanaki 14y ago
There are already implementations of Clojure and Haskell that target JavaScript, but I'm not sure if that's what you meant. I don't know if there are any implementations that target JS using this specific approach but I don't think it's one to necessarily emulate; as nostrademons points out it is interesting, but not really optimal. https://github.com/clojure/clojurescript https://github.com/clojure/clojurescript http://www.haskell.org/haskellwiki/The_JavaScript_Problem http://www.haskell.org/haskellwiki/The_JavaScript_Problem https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS https://github.com/jashkenas/coffee-script/wiki/List-of-lang...
- asimjalis 14y ago
  These are all neat, but they require some effort to bootstrap. The neat thing about Brython is that you can start writing Python immediately. I’ve played with ClojureScript and it takes a while to get the QuickStart to work. I think Brython is cool, not from an efficiency or machine-performance point of view, but from a human point of view. It makes it easy to start hacking. The barrier to entry is non-existent.

tnuc 14y ago

Looks interesting. Certainly a step in the right direction. Are there any specs as to the speed of using this? Javascript can be a bit slow on most days, does Brython make it worse?

jachwe 14y ago

Looks really cool. And i love Python. However, I think the Python Syntax will make it hard to minify the code, which is probably not that important anyway when not in production. But for production usage it would be cool to have a real compiler instead of an interpreter. But yeah. Cool stuff.

limpangel 14y ago
I guess you could just gzip your python code without minification, here's a little bench: https://github.com/jch/gzip_vs_minify https://github.com/jch/gzip_vs_minify

madhadron 14y ago

If you want to do this kind of thing on the server side, Python provides enough introspection to turn functions in a live Python image into JavaScript. Here's a minimal example I tossed together a while back: https://gist.github.com/50d706081074aed8fcf6 https://gist.github.com/50d706081074aed8fcf6 I have a bunch of notes somewhere on translating a big hunk of the basic language, including how to generate continuation passing style code in JavaScript from less ghastly Python. The difficulty is providing all the class semantics and the standard library.

ville 14y ago
I like the simplicity of that gist. Very cool hack. However if I was to implement a Python to JavaScript compiler, would there be some benefits in transforming the Python AST into a JS AST first? There are existing code generators such as escodegen that transform that AST to JavaScript code.

leetrout 14y ago

As a lover of Python myself, this is awesome. However, as others are noting things that are missing that we pythonistas can't live without (generators, classes, etc)- I feel it is worth a reminder that Javascript 6 (Harmony) is going to have a lot of these built in. Brendan's slides have a great overview of what's to come (and makes me hope writing JS outside of CoffeeScript will become more bearable since I'm so spoiled by Python: http://brendaneich.github.com/Strange-Loop-2012/ http://brendaneich.github.com/Strange-Loop-2012/

alecthomas 14y ago

Once upon a time I wrote Oink, which generates JS from Python on the server: https://github.com/alecthomas/oink https://github.com/alecthomas/oink It has support for many of the Python niceties: classes, list comprehensions, positional arguments, and so on. Interesting experiment, but I ended up thinking that Python is not the best language for the browser.

slurgfest 14y ago
Because its syntax can't work with the DOM, or what?

deleted 14y ago

[deleted]

fijal 14y ago

I'm genuinely shocked that this made it to the top of hackernews. I would expect better. While the idea of having the Python interpreter in the browser is very likely better than having a compiler Python -> JS (if we care about Python), the implementation here is both half assed and really bad. It takes quite a bit of effort to create a python interpreter that can be called python. This is nowhere near there. On top of it double-interpretation in dynamic languages is very slow and I doubt someone is willing to pay that price here. A good example of low quality is here: http://code.google.com/p/brython/source/browse/trunk/py_classes.js#140 http://code.google.com/p/brython/source/browse/trunk/py_clas... this is both incorrect (exceptions are propagated, http://paste.pound-python.org/show/28457/ http://paste.pound-python.org/show/28457/) and has wrong complexity. It's not even a dict at all!

why-el 14y ago
I will be more shocked if I discovered that people dive this deep into code before upvoting, because it is generally not the case. If you think of it, we would have missed your valuable input if people didnt upvote this for you to see. :)
tinco 14y ago
It is an indication that we just want to get a python for the web really bad. If someone makes a good looking website for his project it kind of gives the impression that he is seriously going for it, perhaps it is not good now, but maybe it will become a serious contender later.
daemon13 14y ago
All people are different... There are many OPs that assert that JS syntax/lang are beautiful once you get handle of it, and may be it is... However, there may be enough people like myself for whom the JS syntax/lang just do not fit into the brain. Since at my last job of CFO of $200+m pharma country org I have architected multidimensional db for an OLAP cube for SAP Business Objects, I do not think that I am that dumb. But this JS stuff just does not fit in. Also, I do value my time. So although I could persist in learning JS, as a general rule when things do not flow - the learning time multiplies. I do not have time. Hence, personally I would love to be able to write/maintain code in Python [even subset of Python would be fine], knowing that it cleanly compiles to JS. It will be then my choice whether I want it client-side or server-side [smth like what css pre-processors SASS/Less are doing].

TommyDANGerous 14y ago

What? This is insane. Python replacing javascript, insane as in that is super cool. If I could do the exact same things I can do in javascript/query but with python syntax, that would be magical.

kelvin0 14y ago

OK, how about : 1) getting Python ==> LLVM bytecode 2) then using emscripten (https://github.com/kripken/emscripten/wiki https://github.com/kripken/emscripten/wiki) to run LLVM in browser? An option to perform the first step seems to be : http://code.google.com/p/py2llvm/ http://code.google.com/p/py2llvm/ Or 'simply' getting CPython ported on emscripten? Any opinions on this suggestion?

muyuu 14y ago
I've seen that done already, but the resulting Python interpreter has no visibility of the DOM or access to the browser. You have basically a Python console, which is quite useless if what you want is to substitute Javascript.
- zever 14y ago
  Just for reference, there's an example of CPython compiled to JavaScript using Emscripten running in the browser at http://syntensity.com/static/python.html http://syntensity.com/static/python.html