11–20 of 71 posts
(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.
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 .
Not anymore, see Closure Compiler, CoffeeScript compiler, TypeScript compiler, dart2js compiler, and tons more: https://github.com/jashkenas/coffee-script/wiki/List-of-lang... It's pretty common now to call these "compilers".
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.
"""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."""
Good luck with compiling anything without having AST trees and proper parser infrastructure. In it's current state this thing won't fly.
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.
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 .
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.
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 de…
Also worthy of mention in this context: http://pyjaco.org/about and http://pyjs.org/
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.