Do you mean "standard" as in "the community's most often used", or as in "included in the standard library"?
A wise man once told me that "the standard library is where libraries go to die."
Julia is a dynamic language that can compile to fast binary code. Once it can be run in the browser with web assembly, faster and nicer syntax than javascript, why would anyone use python?
There's an XKCD for just about anything...
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.
I didn't check in Python 2, but in Python 3 anyway, `type()` of a `lambda` is definitely `function` and the `lambda` object has a `__code__` attribute with `co_code` containing the actual bytecode, so it's definitely a function.
For raising errors, once again you can just define a helper that does the raising -- the limitation here is the use of statements, not anything inherent to exceptions. For example:
In [56]: def r():
....: raise TypeError
....:
In [57]: f = lambda x: x[0] if isinstance(x, list) else r()
In [58]: f([1])
Out[58]: 1
In [59]: f("hi")
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
<ipython-input-59-987cd5963ca4> in <module>()
----> 1 f("hi")
<ipython-input-57-b0e388d24fbc> in <lambda>(x)
----> 1 f = lambda x: x[0] if isinstance(x, list) else r()
<ipython-input-56-a540441a09db> in r()
1 def r():
----> 2 raise TypeError
3
TypeError:
The same idea would work with context managers, etc.FWIW, having used Python for a long time, I see the limitations on `lambda` as very good things. `lambda` should almost never be used for complex, side-effectful logic, and instead should be used when a short expression needs to be encapsulated and it's easier to do so with an anonymous function than a full function definition, and to a lesser extent sometimes for some tricky metaprogramming use cases, like dynamically binding functions at run time.
I'm sure that high-quality Javascript style probably implicitly uses these same kinds of limitations, even if the language itself doesn't make it mandatory.
I wrote this little library https://github.com/fuhrysteve/marshmallow-jsonschema#complet... 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 also convert it to javascript so that the client can attempt to validate it before bothering to send a web request.
Having a "HOT" interpreter with an execution context that is persistent and can be used to convert code to ES5 on the fly has been already implemented by duckpy creator and i plan to intergate it very soon.
related: a LaTeX to .js "transpiler" for the exercises https://ximera.osu.edu/
Now if only someone could transpile SymPy to javascript...
I'm going to use this in a project I have in mind :)
Do you have any link for this chrome detail about optimization?
str(x) conversion is missing... i'll will implement it asap
[1] http://jayconrod.com/posts/54/a-tour-of-v8-crankshaft-the-op...
It does all without the need for nodejs (even if it can be used of course), it uses an embedded js interpreter.
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?
* as literals;
* in for loops;
Keyword arguments accumulator has no corresponding feature in the ES6 world, as far as I know....
As a feature no, but Python code using that could be easily transpiled to a function taking a dict with the args...
a) make failed b) I didn't really want to build something just to see an example running ;-) c) you don't have an issues turned on in Github so I couldn't file a bug.
It would be lovely if you could host the example somewhere and link to it. Or failing that - have a compiled example in the repo so the idle and curious can try it out with jumping through any hoops.
Listen to this podcast where the author describes the project: https://talkpython.fm/episodes/show/32/pypy.js-pypy-python-i...
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: http://jsperf.com/es6-map-vs-object-properties/73
1. CommonJS modules
2. Static types
3. Webpack loader
Having CommonJS module support will enable polyglot development where language syntax live inside a module and everything follows JavaScript semantics.
2) What do you mean exactly?
3) There's no direct from-python loader, but the compilation can be splitted in two steps with the BabelJS Webpack loader used for the latter