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!
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.
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.
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.
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].
The difficulty is providing all the class semantics and the standard library.
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?
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.
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.
In the end, it was hard to replicate 100% of the usefulness of JS through python and convert python's cool features into JS.
It also supports ruby, scheme, lua and others
What made it impractical was the slowness. Emscripten seems to work fine for clang, not so much for interpreted languages. Maybe the translator path can solve this issue.
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.
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.
(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.
"""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."""
Based on your personal experience - with which one to start?
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.
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.
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.
Brython doesn't implement classes at all, so you're right!
But yeah. Cool stuff.
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.
There is no indication that browsers are going to standardize on a VM (let alone NaCl) any time soon.
If someone just stopped bikeshedding and did Python in the browser, there's no reason a machine-level bytecode or whatever couldn't be implemented later.
But those are libraries under your control at least. The "problem" with Python is that the language itself is big. Normally this is a non-issue, since you can upgrade your interpreter version when your code stack supports it but on the web you don't get that luxury because you are forced to use whatever interpreter the users have.
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.
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 :
Or 'simply' getting CPython ported on emscripten?
Any opinions on this suggestion?
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:
It's pretty common now to call these "compilers".
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.