Brython – A Python 3 implementation for client-side web programming
brython.info
brython.info
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.
def func(param):
for i in xrange(5):
print("Inner");print("AnotherLine");print("YetAnotherLine")
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.
Seems like you missed big announcements the last couple of weeks. Here you can get in the loop:
asm.js/WebAssembly takes care of that.
By contrast, a language that compiles to regular JavaScript can use the GC built into JavaScript.
More security attack vectors? No thanks.
https://github.com/replit/empythoned
It's a pity it didn't get more traction. The effort invested seems a bit more worthwhile.
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).
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.)
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.
I wonder if Guido has suggestions.
[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.)
Thus I really wonder why javascript is better suited for a browser than python.
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.
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.
Almost certainly. PyPy.js does this with asm.js today.
There are, however, features about JS VMs that make them (almost) uniquely suited to browsers. Most notably, almost any other VM has a stdlib including things like open() for local system files — and that'd be considered a massive security exploit. Some languages have features (v. parts of the stdlib) that are insecure in the browser setting — for example the backticks operator in Python. Ensuring an existing VM has had all access to the local system closed off could easily turn into a massive project in and of itself.
> It's hard enough to get browser vendors to agree to standards at all, say nothing about multiple standards for a single feature.
I don't think that's fair — I don't think there's many cases of major browser vendors acting maliciously towards standards in recent times, the only particular examples that stands out to me are the whole pointer/touch events debacle (with Apple withholding patents from the W3C Patent Grant) and the AV codecs mess with various vendors acting selfishly. Otherwise, almost everything seems to be genuine disagreements about how best to do things, especially given market realities.
That's like why developers chose to use linux to develop web applications, and people used those websites, they did not stick to windows software solutions.
It's really important, I think, to keep having different technologies available so that developers can choose what is better. There are many python programmers already, the language is mature and used in many places and I'm sure it could be used in more places.
Blocking?
Also, what about asynchronous operations?
A lot of libraries actually work with python 3. And most of them that don't have a python 3 version in the pipe.
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.