
Brython – A Python 3 implementation for client-side web programming - delian66
http://www.brython.info/
======
thomasfoster96
My only issue with Python being used for client-side web programing is that
significant newlines/whitespace would be an incredible pain if you're inling
things in HTML. Although you would pretty much be forced to use GZip rather
than just minification, which is good-ish.

Plus, loading a 900KB file to run the Python client-side is probably a
terrible idea when you could either transpile to JS or asm.js or (in the
future) WebAssembly.

~~~
stuaxo
It probably could be minified using ;

~~~
thomasfoster96
Which part? A new line is the same amount of data as a semi-colon.

~~~
zo1
Items that are on the same "level" of indentation, I.e. in a codeblock can
have all of them prepended with the whitespace, and then separated with semi-
colons.

    
    
        def func(param):
            for i in xrange(5):
                print("Inner");print("AnotherLine");print("YetAnotherLine")
    

From the example you see that whitespace is still necessary, but you could
"group" items and not have to repeat the whitespace that forms their level of
indentation.

------
josefdlange
I love the thought of being able to use Python on the client side of the web.
We need more commonplace asynchronous paradigms, however.

I do like how this project makes sure to point out that the DOM interface is
intended for consumption by any language and on any platform -- maybe one day
we'll have browsers that come with several languages' runtimes baked in, or
perhaps that can leverage the runtimes for languages already installed on the
local machine.

~~~
eeZi
> maybe one day we'll have browsers that come with several languages' runtimes
> baked in

asm.js/WebAssembly takes care of that.

~~~
skybrian
I don't see how it does. You'll still have to download the language runtime
(including a garbage collector for a language like Python). Perhaps it can be
cached, but that's a heavy requirement for a web page, particularly on mobile.

By contrast, a language that compiles to regular JavaScript can use the GC
built into JavaScript.

~~~
DiThi
If I understood correctly, WebAssembly, unlike current asm.js, will be able to
allocate and use GC objects.

~~~
rictic
Note: a future version of WebAssembly may be able to use the browser GC.

~~~
DiThi
Yes, that's what I meant.

------
etanol
Related project:

[https://github.com/replit/empythoned](https://github.com/replit/empythoned)

It's a pity it didn't get more traction. The effort invested seems a bit more
worthwhile.

~~~
pekk
What makes it more worthwhile?

~~~
tim333
And given "Empythoned is a build script that uses Emscripten to compile
CPython for use in a browser", isn't compiling Python to C to Javascript going
to end up a bit clunky compared to just writing Javascript?

~~~
0x0dea
[https://www.destroyallsoftware.com/talks/the-birth-and-
death...](https://www.destroyallsoftware.com/talks/the-birth-and-death-of-
javascript) is non-fiction.

------
knocte
I see that to use Brighton you need to import a bryton.js file and call
"bryton()" on the onload event of the <body> element, and this rings my bell:
isn't this a downside compared to normal javascript code?

Non-trivial web pages will take a bit to download fully and load, and
sometimes you need your javascript code to act as quickly as it can (that's
why very often the js <script> tags are all over the place in the HTML code,
not just at the beginning and activated by the onload event).

~~~
pekk
Yes, Javascript will still be the fastest option with the cleanest support.
That's because browser vendors have intentionally put everything else at a
disadvantage (Mozilla ensuring nobody puts Brendan Eich's baby in a corner).
The most anyone can really do is generate slight variations on the spelling of
Javascript, which has other big disadvantages. All of this is a downside
compared to normal programming.

~~~
woah
It's all a huge conspiracy

------
nrser
it would be nice if the site or github repo had some information about how it
actually works

------
phanindra_veera
I'm not sure why we need python for the client side web programming, when JS
is already used everywhere for that. Does it have to do any issues with JS or
it's because Python is easy ? Please enlighten me here.

~~~
douche
Because if Python is a hammer, Javascript is a Fisher-Price toy hammer. It's
amazing that such a shit language has become so ubiquitous.

~~~
wwweston
I've been using both for a while now -- JS for 15 years, Python for five. I
expected some big revelation given the consensus that Python is clearly
better.

I like working in Python, but I'm still waiting for that revelation. As I can
tell, if you can't be as productive in JavaScript as you are in Python, you're
either not actually productive in Python, or you never bothered to learn
JavaScript.

(I appreciate people who are nevertheless insistent about Python's superiority
without bothering to provide any kind of supporting argument, though -- it
lets me know how safe I am in disregarding an opinion where I used to think I
was probably missing something -- so if you want to recapitulate the quality
argument I'm responding too, feel free.)

~~~
douche
Python doesn't have the whole == vs === debacle.

Python has a string library that makes some kind of goddamn sense (because it
matches the C implementation). When I realized that in JS,
foo.replace('bar','fizz'); only replaces one instance of 'bar', my head
exploded. Then there is the lack of real integers, and all the bullshit
ToStringing() that can happen at runtime if you aren't hyper-vigilant.

------
sunilkumarc
Looks very interesting! But I don't understand how python is being executed in
a web browser. Is there any run time in the browser that I'm missing out(like
V8 for JavaScript)?

~~~
tim333
Apparently the brython.js script translates Python into Javascript, on the fly
in the browser and because of this the programs tend to run 3 to 5 times
slower than normal javascript. (from the Brython faq)

------
jokoon
Writing a firefox module or addon that adds native python support seems like a
nice idea for an open source project...

I wonder if Guido has suggestions.

~~~
tim333
Guido in 2013:

[Question: ...] is it time to give up on python in the browser ?

Guido: I gave up on it in 1995, so yes. And please don't try to compile Python
to JavaScript. The semantics are so different that you end up writing most of
a Python runtime in JavaScript, which slows things down too much.
(CoffeScript's strength is that it is designed to map cleanly to JavaScript,
and the two are now co-evolving to make the mapping even cleaner.)

~~~
jokoon
I wonder why he gave up. I guess if it's mostly for technology choices, or if
there are genuine reason to not put python in the browser.

Thus I really wonder why javascript is better suited for a browser than
python.

~~~
moron4hire
It's politics, not technology. One could make a browser scripted via python,
but it would be an extreme minority position and would fail to gain adoption.
One could add python support to any existing browser, but none of the
stakeholders care enough to do it; they will always argue it is a waste of
time because <insert other popular browser> doesn't do it.

There is nothing about JavaScript that is uniquely suited to the browser, it
just "won out". It's hard enough to get browser vendors to agree to standards
at all, say nothing about multiple standards for a single feature.

~~~
rictic
I think the lesson that the last few years have taught us is that you can do
ambitious things, but to get buy in it needs to be an incremental and gradual.
This is the cost of a large system with >4 largely independent implementors
with significantly distinct plans and goals.

It's not too hard for me to imagine a near future with smooth python support
in the browser. A webassembly python runtime with GC integration in the
browser served trustlessly and with a high cache hit rate from a CDN using
subresource integrity (and perhaps with even the popular runtimes packaged
ahead of time in browsers). It might be possible to load and run the python
source through the webassembly runtime using the ES6 module loader. I wonder
if we'll even see JITs in webassembly-based interpreters that compile code
that they're interpreting down to webassembly.

~~~
gsnedders
> I wonder if we'll even see JITs in webassembly-based interpreters that
> compile code that they're interpreting down to webassembly.

Almost certainly. PyPy.js does this with asm.js today.

------
curiously
This has potential but why 3? Why not 2.7?

Also, what about asynchronous operations?

~~~
aroberge
2.7 is a dead end. Python 3 is now at least 7 if not 8 years old. Brython was
obviously created with the future, not the past, in mind.

~~~
curiously
lot of libraries won't work with python 3 which is why 2.7 still matters,
besides, plenty of people prefer 2.7 over 3, 3 is kinda weird.

~~~
Nemcue
> lot of libraries won't work with python 3 which is why 2.7 still matters

A lot of libraries actually work with python 3. And most of them that don't
have a python 3 version in the pipe.

[http://py3readiness.org/](http://py3readiness.org/)

------
mc_hammer
just a heads up

if you are using python on your server to parse and process Python dont use
eval, and escape whatever quotes the input is coming in with... there at least
10 ways to spawn a command console on python.

