
Brython, Python in the browser - dagw
http://brython.info/index_en.html
======
willvarfar
It actually translates Python into Javascript! I'm thoroughly impressed.

Another approach that may work in Chrome is to use Chrome Native Client to
embed a 'proper' Python runtime.

I've often lamented that we have Javascript and not Python :(
[http://williamedwardscoder.tumblr.com/post/20771096806/why-d...](http://williamedwardscoder.tumblr.com/post/20771096806/why-
didnt-we-use-python-in-the-browser)

~~~
cookiecaper
_Completely_ agree that Python ought to be the default browser scripting
language. Far, far better than JS. I've always been excited about the prospect
of NaCl because it may be able to help us make that a reality in some limited
contexts.

~~~
louischatriot
Python noob here, I am very interested in what you think makes Python a better
browser scripting language than JS (which I use a lot on client and server
side and like very much).

~~~
willvarfar
It is surely subjective. Not the person you reply to but I'll chip in anyway.

I write lots of Javascript; mostly 'raw' Javascript in the webGL space. Here's
just of the top of my head what's wrong with Javascript:

* looping over elements has too much boilerplate

* the mindfulnesss of 'this' is distracting

* the duality of dictionaries and lists and how that's an easy lie to fall for is fustrating

* that there are multiple frameworks trying to use $

On the other hand, their anonymous functions are very nice. And, I rather like
prototypes vs classes. A bit. Sometimes

With Python, I _like_ significant whitespace (so sue me) and especially the
syntax for collections and packing/unpacking them.

I've blogged along these lines a lot in the past e.g.
[http://williamedwardscoder.tumblr.com/post/18319031919/progr...](http://williamedwardscoder.tumblr.com/post/18319031919/programming-
language-readability)

~~~
jashkenas
With that particular list of features and complaints, you may want to take a
quick look at CoffeeScript. It addresses everything on the list except for the
"multiple frameworks trying to use $" bit.

~~~
acjohnson55
I think the $ point is a bit soft anyway. With jQuery, it's easy enough to
just use non-conflict mode.

~~~
sim0n
It's not often you want to use two libraries that both use $ anyway (e.g.
you'd use jQuery OR prototype, Zepto OR MooTools - not usually both).

~~~
willvarfar
Funnily enough, it was trying to use a box2d port that used prototype in an
app that already used jquery that raised my hackles most recently...

------
aidos
This was posted a couple of months ago - discussion here:
<http://news.ycombinator.com/item?id=4923530>

------
tferris
I am impressed but I'm also wondering why people try to avoid learning new
stuff -- to potential downvoters, no rant intended. I am just surprised how
many people try to circumvent JS: Rubyists with Coffee, Closurists with
ClosureScript, etc. instead of just using JS directly. I don't believe the
main motivation is JS' potential inferiority and that you could employ much
better design pattern with languages compiling to JS. Neither, JS' syntax is
bad or ugly. I assume that's it's the fear of learning something new, to be
again a beginner. JS has its quirks but in general it's a very modern and
beautiful language and offering more innovation than traditional scripting
languages. And V8 is so blazingly fast that I sometimes think this feels more
like C compiled code which would be just another reason rather to switch to JS
in the backend.

~~~
eric_bullington
I can't speak to ClojureScript, but in my experience, CoffeeScript is
primarily used by people who _already_ know JavaScript. You can't use
CoffeeScript effectively without understanding JavaScript. Most of us who use
CoffeeScript instead of JavaScript appreciate CoffeeScript's syntactic
shortcuts, which for us makes it quicker to write and improvise with new
ideas, as well as its enforced whitespace, which makes it easier to write
maintainable code.

Otherwise, as someone whose first and second strongest languages are Python
and Javascript, I agree with you. JavaScript is a beautiful language that
accommodates a variety of programming styles. As you mention, JavaScript is
also much more performant than Python, which makes me questions whether Python
would ever be a viable replacement for JavaScript in the browser. Add to that
JavaScript's excellent webworker API compared to Python's choices for parallel
programming.

Now, Lua, on the other hand, would be an excellent browser language
(specifically the LuaJit implementation). Lua is close enough to JavaScript
that folks could easily pick it up, and its blazing fast. But it will never
happen.

Besides, there are so many great JS libraries now that in most cases, I
wouldn't want to switch to Lua in the browser and face re-inventing the wheel
(same reason why I generally use Python instead of Lua elsewhere). But its fun
to think about.

~~~
tferris
> makes it quicker to write and improvise with new ideas,

I've never thought about that but could make sense.

> as well as its enforced whitespace, which makes it easier to write
> maintainable code.

This is something I've never understood and where I tend to disagree. When
starting with "whitespace" languages like Coffee, Ruby or Python people
initially are please with clean and tidy looking code but in the long run this
code is not maintainable since all the white space makes the code looking not
distinctively enough. In contrast, bracket based languages like C or JS give
much better orientation. I can quickly see where code blocks start or I can
immediately recognise functions etc.

> Lua, on the other hand, would be an excellent browser language

Totally agree

~~~
njharman
Ruby is not a significant indentation language. do not comprehend how
Indentation is not visually distinctive.

~~~
tferris
I didn't mean the indentation, I meant leaving away brackets.

------
dbaupp
This was posted previously at <https://news.ycombinator.com/item?id=4923530>,
along with some fairly extensive discussion and criticism.

The basic gist of the criticism seems to be the code is basically just
directly translating a Python token list ( _not_ an AST) into Javascript, and
as such is reasonably fragile and horrible code (the main translator function:
[https://code.google.com/p/brython/source/browse/trunk/py2js....](https://code.google.com/p/brython/source/browse/trunk/py2js.js#52)
).

------
lucian1900
This isn't a particularly good implementation, though. Looking through the
code, it's not something I'd be comfortable using.

Skulpt is much better, and about as incomplete.

------
jarek-foksa
I don't like the fact that underscore and camelCase notations must be mixed,
e.g. in the clock demo:

    
    
        def set_clock():
          ctx.beginPath()
          ctx.fillStyle = "#FFF"
          ctx.arc(width/2,height/2,ray*0.89,0,2*math.pi)
          ctx.fill()
          show_hours()
    

This is not the case with some other languages that compile to JavaScript,
e.g. LiveScript allows dash-case almost everywhere.

~~~
peller
They don't; it's purely a matter of convention that Python style guides prefer
under_scored over camelCased. But you are entirely free to implement all of
your python functions and variables and whatnot in camelCase, and in fact,
many libraries do.

~~~
peller
You could probably even try to write a decorator that converted under_scores
function names to camelCase for a nice little introduction into various parts
of some of the more internal pieces of python.

~~~
_ZeD_
uhmm, AFAIK pep8 suggest UpperCamelCase for classes, under_score for packages,
methods and functions[0]

btw: it's not a decorator :) but a camelCase->under_score renamer it's pretty
easy to write

    
    
        import re
        
        def unCamel(obj, *maybe_camels):
            if not maybe_camels:
                maybe_camels = filter(lambda n: not n.startswith('_'), dir(obj))
        
            for maybe_camel in maybe_camels:
                underscore = re.sub(r'([^A-Z])([A-Z])([^A-Z])',
                    lambda m: '%c_%c%c' % (m.group(1), m.group(2).lower(), m.group(3)),
                    maybe_camel)
                if underscore != maybe_camel:
                    setattr(obj, underscore, getattr(obj, maybe_camel))
        
        if __name__ == '__main__':
            class CamelCase(object):
                def multiWordMethod(self):
                    print('called multiWordMethod')
            
            def multiWordFunction():
                print('called multiWordFunction')
        
            unCamel(CamelCase)    # magic
            import sys
            unCamel(sys.modules[__name__], 'multiWordFunction')    # magic
        
            CamelCase().multi_word_method()
            multi_word_function()
    
    
    
    

[0] <http://www.python.org/dev/peps/pep-0008/>

------
limitlessbooks
How is the performance impacted?

I could see myself using this for a SaaS app I am developing right now; would
be useful to run the same language on the client as on the backend. But it
needs to performant in this case.

------
StavrosK
How do these things happen? One moment, I know nothing about a lightweight
Python interpreter in JS (a thing I would have heard about, even if it were in
its infancy), and I see a full-blown interpretation the next.

I'm amazed at how this has slipped past me so far. Does anyone know the
specifics on how it works (performance, does it implement the complete
language, etc)?

------
omershapira
Wonderful. Now give it a name that doesn't sound like "Bro-Python" and I'm
sold.

------
Tekker
Is this just a translator Python->Javascript (which I would expect would have
many holes in it) or is it being run by a true Python engine?

And if it's run by a true Python engine, does the user have to have Python
installed do run it? (Hard for me to tell since all my machines ATM have
Python installed).

~~~
gejjaxxita
It's a translator and I agree it would probably have many holes in it. Also
can you imagine importing libraries?

------
friendly_chap
Compared to the original JS demo (linked on page), the version transpiled from
python looks really choppy.

------
denzil_correa
Looking for something like this since a long time now. Essentially, you have
made a Google Web Toolkit (GWT) for Python. Good work, I hope it matures to a
level and is widely adopted. Best luck!

~~~
okhan
GWT was actually ported to python a while back. The project lives on at
pyjs.org

------
tsahyt
Brilliant. Now let it run natively in the browser rather than compiling to JS
and you made the world a better place!

------
lemcoe9
He should call it pQuery!

~~~
draegtun
Already taken! - <http://www.pquery.org/>

Also see: <http://ajaxian.com/archives/pquery-php-and-jquery> |
<https://metacpan.org/release/pQuery>

~~~
_ZeD_
and pyQuery too - <http://pypi.python.org/pypi/pyquery> (btw it's a really
good way to handle xml)

------
leke
I think I prefer the Google/Dart approach -- that is, a language designed for
the web browser and that has a native engine for the browser (although only
currently included in chrome).

------
pizu
Please upvote it you need Brython for Ruby!

~~~
azakai
<http://qiezi.me/projects/mruby-web-irb/mruby.html>

------
thomasrambaud
I find it a bit the overkill. If you'd like to implement Python in the
browser, at least make sure to write a good implementation. An implementation
written in JavaScript, is not a good implementation.

~~~
arnarbi
> An implementation written in JavaScript, is not a good implementation.

Do you have some evidence for this, or are you just judging it by the fact it
is written in JavaScript? I can imagine source-to-source translation between
Python to JS that would provide an excellent implementation of Python.

