
Brython - Python to Javascript translator - toni
http://www.brython.info/index_en.html
======
fijal
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_clas...](http://code.google.com/p/brython/source/browse/trunk/py_classes.js#140)

this is both incorrect (exceptions are propagated, <http://paste.pound-
python.org/show/28457/>) and has wrong complexity. It's not even a dict at
all!

~~~
hosay123
> has wrong complexity

Python doesn't specify the complexity of dicts, that they're "efficient" is a
CPython implementation detail other runtimes happen to copy. Even a worse-
than-linear time mapping that satisfies the protocol is still a 'dict'.
Surprised you don't know this given your relationship to PyPy.

As for whether I'd prefer a 100kb "not quite Python" or sending a few MB of JS
(that takes 10 minutes to translate for each change) to the browser just to
handle a few functions in a cross-platform manner, I'm glad to see more
options when making this choice.

I'm in the midst of evaluating a solution to running simple mathematical
functions on a Python backend or in-browser (for graphing). In a case like
this, a handful of crappy guarantees about the lowest common denominator
arithmetic is all I need in a solution. It's easy to get wrapped up in
correctness, but ease and practicality trumps it almost every time.

~~~
fijal
indeed, python does not specify the complexity, it's just what everyone
expects.

Anyway, my problem is not with "not quite Python", my problem is with calling
it "Python". As long as you call it "a language with Python inspired syntax",
it's seriously left to the reader whether he likes it or not. If you call it
Python, it's fine to have something incomplete, however provide a way forward
at least. This seems to be incredibly far from supporting full Python, which
might or might not be a goal.

------
madhadron
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>

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
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.

------
mahmoudimus
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
Once brython gets some key missing Python features (classes, list
comprehensions, lambdas), and some libraries for it, I think it has huge
potential.

~~~
nnq
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!

------
DanielRibeiro
Repl.it has supported python on the browser for a while: <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>

[2] <https://developer.mozilla.org/en-US/demos/detail/bananabread>

~~~
azakai
> 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.

------
dbaupp
This looks really nice! It seems like the other side of the Python-in-the-
browser coin to Empythoned (<https://github.com/replit/empythoned>) used by
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
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
Oh, neat. Thanks for the pointer!

------
T-A
Also worthy of mention in this context: <http://pyjaco.org/about> and
<http://pyjs.org/>

~~~
lost-theory
And <http://www.skulpt.org/>

------
javis
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.

------
GauntletWizard
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.

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

~~~
nostrademons
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.

~~~
asimjalis
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
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.

------
jachwe
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
I guess you could just gzip your python code without minification, here's a
little bench: <https://github.com/jch/gzip_vs_minify>

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

~~~
trothamel
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
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.

~~~
greggman
What about pnacl?

[http://www.chromium.org/nativeclient/pnacl/building-and-
test...](http://www.chromium.org/nativeclient/pnacl/building-and-testing-
portable-native-client)

~~~
Niten
I had no idea about that, thanks

------
alecthomas
Once upon a time I wrote Oink, which generates JS from Python on the server:
<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
Because its syntax can't work with the DOM, or what?

------
kelvin0
OK, how about :

1) getting Python ==> LLVM bytecode

2) then using emscripten (<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/>

Or 'simply' getting CPython ported on emscripten?

Any opinions on this suggestion?

~~~
muyuu
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
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>

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

------
TommyDANGerous
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.

------
leetrout
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/>

------
awolf
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_.

~~~
tantalor
Not anymore, see Closure Compiler, CoffeeScript compiler, TypeScript compiler,
dart2js compiler, and tons more: [https://github.com/jashkenas/coffee-
script/wiki/List-of-lang...](https://github.com/jashkenas/coffee-
script/wiki/List-of-languages-that-compile-to-JS)

It's pretty common now to call these "compilers".

~~~
nostrademons
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.

------
tnuc
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?

------
asimjalis
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
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>

<http://www.haskell.org/haskellwiki/The_JavaScript_Problem>

[https://github.com/jashkenas/coffee-script/wiki/List-of-
lang...](https://github.com/jashkenas/coffee-script/wiki/List-of-languages-
that-compile-to-JS)

~~~
asimjalis
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.

------
halayli
No support for python classes?

