Can all of you python to javascript library creators get together and create one solid library, or maybe not all of you, because it would be a grid-lock of decisions. How about half of you with the most similar ideas get together and do one super solid library, instead of having 20 of these python to javascript libraries so the community can easily decide on one to use as a standard. This would be awesome! Thanks!
I'm a little horrified to suggest this seriously, but this could be a cool way to accomplish consistent field validation between server and client.<p>I wrote this little library <a href="https://github.com/fuhrysteve/marshmallow-jsonschema#complete-example-flask-application-using-brutisinjson-forms" rel="nofollow">https://github.com/fuhrysteve/marshmallow-jsonschema#complet...</a>
to convert marshmallow schemas to a JSON representation with the intention of passing it to a browser or mobile device for rendering. Imagine if you could also pass native code to be used by the client for validation. In other words: write your validator in python and use it server side - but <i>also</i> convert it to javascript so that the client can attempt to validate it before bothering to send a web request.
Looks interesting, but it has naming incoherences: 'pip install javascripython' actually installs in site-packages/metapensiero/pj. I don't get why it does not simply install in site-packages/javascripthon.
If you want to build the web with Python, IMO the emphasis should be bringing Python to the web. I think a more promising project is <a href="http://pypyjs.org/" rel="nofollow">http://pypyjs.org/</a> - a Python runtime in your browser powered by asm.js<p>Listen to this podcast where the author describes the project: <a href="https://talkpython.fm/episodes/show/32/pypy.js-pypy-python-in-your-browser" rel="nofollow">https://talkpython.fm/episodes/show/32/pypy.js-pypy-python-i...</a>
This is awesome! One comment, it might be a good idea to make the docstrings in JS appear above the functions rather than inside them? Chrome refuses to optimize functions if they are above a certain size in bytes, which includes comments, so it seems most 'docstrings' are placed above the definition rather than inside. Also does str(x) convert to x.toString(x)?<p>I'm going to use this in a project I have in mind :)
For-in array can be implemented using ES6's for-of.
<a href="https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Statements/for...of" rel="nofollow">https://developer.mozilla.org/en/docs/Web/JavaScript/Referen...</a><p>Also, Not sure if it would be correct to implement a python dict using an ES6 map. If the keys are all strings, probably better to stick to a JS object.
Check out the performance difference:
<a href="http://jsperf.com/es6-map-vs-object-properties/73" rel="nofollow">http://jsperf.com/es6-map-vs-object-properties/73</a>
Python and modern JavaScript seem like fairly similar languages (dynamically typed, object oriented/functional hybrid, rich ecosystem of packages), the biggest difference being Python's "batteries included" standard library, which presumably isn't (all?) available in the browser.<p>So is the main reason to use this just familiarity with Python, minimal context switching if your backend is in Python, and the potential for a bit of code reuse between front/backend?
Related: <a href="https://blog.glyphobet.net/essay/2557" rel="nofollow">https://blog.glyphobet.net/essay/2557</a><p>By the way, I prefer Javascript's scoping rules over Python's. Also, it is easier to create a lexical block in Javascript than in Python.
It's Python with javascript ES6 semantic, there is no support for Python list, dict or support for Python magic parameters <i></i>kwargs. Good work nonetheless.
Does this support:<p>1. CommonJS modules<p>2. Static types<p>3. Webpack loader<p>Having CommonJS module support will enable polyglot development where language syntax live inside a module and everything follows JavaScript semantics.