Yeah weird. I would expect Python2 to be dying off more by now. Wonder if we're headed to an environment where there's essentially 2 separate languages as Python 3 continues to change and grow?
I think we're roughly already there. I think the pivotal moment where Python 2 could've died out rapidly passed and they kept officially supporting it for too long.
As far as I know, permanent EOL for Python 2 is still Jan 1, 2020 (https://pythonclock.org/). Python 3 was first released December of 2008. That's an awfully long tail.
Fascinating. I always thought Python 2.7 support would end July 3, 2020 (exactly 5+5 years from when 2.7 was released), but for some reason they recently decided to go with Jan 1st.
> Specifically, 2.7 will receive bugfix support until January 1, 2020. All 2.7 development work will cease in 2020.
> I've updated the PEP to say 2.7 is completely dead on Jan 1 2020. The final release may not literally be on January 1st, but we certainly don't want to support 2.7 through all of 2020.
It's a pretty old side-project, based on an interpreter that itself took quite a while to support Python 3 well due to lack of funding, so it's not that weird it hasn't been updated.
I still get surprises like starting to learn Google Cloud Functions and realizing that up until July of this year they only supported Python 2.
I have no idea why would a project of this caliber would start by using Python 2 instead of Python 3.
Edit: When I started reading about GCF, all docs said I could only use Python 2. Later I found that they seem to be on the way to change this. But still, I was very surprised that Python 2 was even an option to begin with.
WASM plans on adding GC, polymorphic inline cache, direct DOM access, etc. That would allow for Python without having to download the whole runtime. Whenever that happens, it might become more mainstream. Similar for other languages.
There have been js/asm.js CPython builds demoed since early days of emscripten, and emscripten is the main WebAssembly toolchain, so it's "just worked" since the beginning.
This is pretty old, and hasn't seen an update in over a year. I never understand why links links this get posted with no discussion to start it off with.
Also, wouldn't this be better implemented with WASM?
Such a snarky response, but I can't deny it. I see a JS package that hasn't been updated in a year and I expect that it won't even build with my environment because webpack evolution. I see a python package that hasn't been updated in a year and it doesn't faze me. Not a whole lot that can break in terms of building and integration with my python project.
Perspective is everything. Now and again I use C libraries that haven't been updated in 15 years. Why? There isn't a need. Everything builds perfectly, and some of those libraries are still the go-to solutions in my field.
Its front page describes it as an experiment, and it has 98 open bugs. Both PyPy and Python have released new versions since the last update of this project, so it's at least missing important updates.
Limited man-hours, and more time being spend on the data-science community? I've seen a fair number of impressive things done targeting data-science, but less big generally useful libraries.
A lot of the low-hanging fruit for generally-useful libraries have already been created, and have reached maturity?
Micropython is pretty recent, and pretty impressive.
It's moved from "growing" to "well established." I don't see many people lamenting something is in CPAN and not pip anymore. It shouldn't be surprising that you find more stale projects and packages as time goes on. Most of the interesting stuff is in the development with specific packages (Pandas, Salt, OpenStack, etc.).
I tried to do a little something with Emscripten and WebAssembly, but I stopped on the sockets implementation. It relies on WebSockets. I wonder how well we could emulate real sockets using WebRTC to make WebAssembly apps more sophisticated.
I'd love there to be a client-side webapp development system using Python with feature and output parity to JavaScript. If it was a product, I would buy it.
I've been thinking about building this for Tcl. Tcl has been available in the browser in various forms for decades, but one thing that makes Tcl uniquely suited to a web application style development is its threading model. In Tcl, you access a thread by sending messages to it, in which a Tcl interpreter inside its event loop processes. My plan was to have a client-side Tcl program in the browser that automatically instantiates a second thread, but the thread is a remote thread running on the server, so you would be able to access the server just as if it were another thread.
Something like (client-side):
thread::send $::tcl-web::server -async {
do stuff
} placeToStoreResult
...
vwait placeToStoreResult
do stuff with result $placeToStoreResult
>Then you GET to code in Tcl !
I don't care about Tcl but your enthusiasm is golden. Sort of why I write silly stuff in bash or in an esoteric manner; "Why" "Cause we can!!"
You should give Nim a try. It's a Python-like language which can be compiled to C and JavaScript. There is even a SPA framework[1] for it already and the NimForum[2] is written in it.
I'd expect a much larger difference in tasks that are pure Python (loading a CSV is done primarily through the csv module, i.e. all the hot loops are in C).
It's not "overhead from sandboxing" that's a problem, it's the fact that translating from bytecode to bytecode to bytecode will cause it to lose some ... succinctness at each step, giving the final machine code generator a harder time coming up with efficient code for it.
this is pretty neat! I was wondering, are there any projects to transpile python to js, but targeting the server side? It would be interesting to port a flask application, for example, to run on node and benefit from the jit, or maybe use express and call flask through its wsgi interface.
There's no python standard, but my guess is that-- since this is based on the same source code that native PyPy is, with a different compiler backend -- they are making the claim based on the fact that native PyPy is widely considered to be similar enough to CPython for many workloads. Thus -- assuming the correctness of the RPython -> JavaScript transformation (which they have not proven, and would be a monumental task) -- you should expect this version to work like the native PyPy.
Didn't we decide a long while back that fully featured programming languages were dangerous in the browser, especially if they could do disk I/O? Even if sandboxed? A la Java Applets and Adobe Flash?
import os
for subdir, dirs, files in os.walk('./'):
for file in files:
print file
os.remove(file)
Perhaps the environment is "fake", and these files don't really exist, even in some sandbox... otherwise, seems like this might pose a security risk.
I don't know about PyPy.js specifically, but most systems like this provide a virtual filesystem that maps back to things like indexedDB and localstorage which are browser APIs.
There is no way that pypy.js is able to access local files on your machine outside of the browser sandbox.
No, not in this case. It's running in JS land in the browser so any exploits to break out of the browser sandbox using this could be done simpler with raw JS.
This is Javascript, not real Python. If you're so afraid that this is dangerous, why do you post malicious code? And if you're so clever to post that code, why don't you try similar code to see if it really has access to your files?
> If you're so afraid that this is dangerous, why do you post malicious code?
That's not malicious code... it removes files from a sandbox... you can refresh the page and see for yourself.
> And if you're so clever to post that code
There's no need to be rude... there's an honest question and lack of understanding in my post - educate me, don't talk down to me.
> why don't you try similar code to see if it really has access to your files
The question was if someone could break out of a sandbox, such as with Java Applets and Adobe Flash. I have no idea how to do that - I'm not a security specialist, nor some sort of hacker guy.
> The answer, by the way, is no.
From the sandbox and using the standard `import os`, ya, you're right. The question, again, is what if someone got outside the sandbox?
Thanks for the elaborate response, now I much better understand what you're trying to say.
This is different from the examples you mention: there is no external software that creates the sandbox (whereas with Java and Flash you had to install those as plugins). It's really just Javascript as it is built into the browser. Any vulnerability in this "sandbox" is a vulnerability in the browser, not some 3rd party plugin.
Put differently, this pypy emulation is no different from the Javascript API that was in your browser already. This isn't a new plugin, just using Javascript to emulate Python through the Pypy interpreter.
The speed is surprisingly reasonable. Testing with a simple loop, I get about 1.3-1.4 million loops per second in python3, 2 million loops per second in python2, 14.5 million loops in pypy, and 0.61 million loops in the browser.
My code basically calls int(time.time()) until its value changes, doing i+=1 for every time it did not change (n=10 for every platform (python2/3/pypy/browser)). My browser is Firefox 61, full code here: https://hastebin.com/turenofise.py
I wonder if the time.time is the slow part there? Maybe worth doing a busy look for say 5 million iterations, timing that then doing the calculation for loops per second.
I'm sure it is a thousand times slower than i++, but it should be the same code on each platform.
But you made me think: indeed, the underlying call could be slower from JS whereas from pypy/python{2,3} it's fast (or vice versa). So I just tested a version where it checks how long ten million iterations take (n=3). Code here: https://hastebin.com/uyuhecabek.py
Since there is no syscall to be made, pypy can do this in compiled code and is blazingly fast (I bet C/assembly isn't much faster there), and the rest seems comparable to the previous estimate: the browser version is 2.25× slower compared to python3 (now 2.43×) and 3.33× slower compared to python2 (now 3.70×).
I'm surprised it's that different; in the optimum case, it feels like a several layers of JITing interpreter should get to the same performance in the end. Might not be enough to trigger it I guess.
I can't see the code because I'm on mobile, but if the JIT is function based and you're only calling the benchmarked function once it may not have it optimized for your first call. It certainly can't replace the instructions mid-loop.
Iteration 0 took 0.6579999923706055s
Iteration 1 took 0.6540000438690186s
Iteration 2 took 0.6460001468658447s
(I noticed the code from hastebin was an old version, I forgot to swap the starttime-time.time() in the version I posted. Not that it matters much, just change the sign.)
Running it on OP's website again just to be sure, it now takes 4.9 seconds instead of 5.25, so there is some variance there, but this is still a big difference. This is Firefox as well (see another comment in this subthread), I don't have Chromium installed.
Won't this calculation overflow to +Infinity in JavaScript after a while? On the other hand, Python will try to compute the actual result using arbitrary precision integers, which is that's slower.
Python 3.6.6 from Debian Buster in a VirtualBox VM on a Windows 10 host. Testing with 3.7.0, the result is no different. Python 3.5 is no longer available in the repositories to test whether that is indeed slower.
Fetching time in the browser isn't accurate because a lot of trackers exploit timing in order to fingerprint users. A lot of browsers now purposefully reduce the precision of the clock. See:
Oh, how convenient. Sometimes I wonder if we shouldn't find a way to be able to run trusted applications instead of making everyone's life difficult all the time, and that's speaking as a security consultant, not even a developer... but yeah I don't see a good way to make that happen.
I believe emscripten provides a virtual filesystem interface. Since it's essentially translating/running c it's either hooking through glibc or the syscall interfaces.
If the Python module was large and complex, it does something that would be incredibly difficult to replicate in nodejs either given the current ecosystem or costs of a rewrite, is not available in Rust/C/C++ that could be WASM'd (not mentioning others here due to large WASM overhead), you accept the large binary sizes of these things (i.e. you're not embedding the Python interpreter/runtime and putting on npm), and you're willing to put a node-friendly layer on top that makes the lower level calls...then it might be sane. But I'd consider modernizing to an updated emscripten that does WASM, see if you can avoid some emscripten runtime (i.e. WASM standalone compilation).
For all other cases, stay in Node or use a lib from a language more suited to WASM compilation. Now, if it's an option between this and a native Node module, that depends on your opinion of Node FFI and native Node modules.
Really amazing. I use python every day at work, and most of the crucial libraries have tight inner loops written in C or Cython. I wonder what the web assembly future holds for those languages, and inter-language FFI.
128 comments
[ 3.8 ms ] story [ 178 ms ] thread> Specifically, 2.7 will receive bugfix support until January 1, 2020. All 2.7 development work will cease in 2020.
> I've updated the PEP to say 2.7 is completely dead on Jan 1 2020. The final release may not literally be on January 1st, but we certainly don't want to support 2.7 through all of 2020.
https://www.python.org/dev/peps/pep-0373/#maintenance-releas... https://mail.python.org/pipermail/python-dev/2018-March/1523...
I have no idea why would a project of this caliber would start by using Python 2 instead of Python 3.
Edit: When I started reading about GCF, all docs said I could only use Python 2. Later I found that they seem to be on the way to change this. But still, I was very surprised that Python 2 was even an option to begin with.
What I gather is that it's compiling CPython to WASM and ships it along with some other utilities. It looks pretty cool.
Also, wouldn't this be better implemented with WASM?
So pretty much like every Python project then. What's happening to the Python community?
If you've been writing JavaScript your whole career you might not know what that looks like.
A lot of the low-hanging fruit for generally-useful libraries have already been created, and have reached maturity?
Micropython is pretty recent, and pretty impressive.
It's moved from "growing" to "well established." I don't see many people lamenting something is in CPAN and not pip anymore. It shouldn't be surprising that you find more stale projects and packages as time goes on. Most of the interesting stuff is in the development with specific packages (Pandas, Salt, OpenStack, etc.).
Something like (client-side):
However the language I yearn for in browsers is Lua.
1 - https://github.com/pragmagic/karax
2 - http://forum.nim-lang.org/
To my surprise it was faster than Jupyter / CPython for some tasks (e.g. loading and parsing large CSVs).
http://speed.pypy.org/
I'd expect a much larger difference in tasks that are pure Python (loading a CSV is done primarily through the csv module, i.e. all the hot loops are in C).
I'd expect some overhead from sandboxing etc., but it should be fairly close to native speed.
Naturally, I changed the first code block to this:
hello
>>>import json
>>>
Dope, everything I need.
Why, exactly, does this have such a garbage-ancient version of Python?
There is no way that pypy.js is able to access local files on your machine outside of the browser sandbox.
2. uh ok I'll paste it into an editor and remove the added indentation and then copy&paste that to test it
3. ... ok. I'll look at the code and reformat every single line and copy&paste that
the oldest complaint abides
That's not malicious code... it removes files from a sandbox... you can refresh the page and see for yourself.
> And if you're so clever to post that code
There's no need to be rude... there's an honest question and lack of understanding in my post - educate me, don't talk down to me.
> why don't you try similar code to see if it really has access to your files
The question was if someone could break out of a sandbox, such as with Java Applets and Adobe Flash. I have no idea how to do that - I'm not a security specialist, nor some sort of hacker guy.
> The answer, by the way, is no.
From the sandbox and using the standard `import os`, ya, you're right. The question, again, is what if someone got outside the sandbox?
This is different from the examples you mention: there is no external software that creates the sandbox (whereas with Java and Flash you had to install those as plugins). It's really just Javascript as it is built into the browser. Any vulnerability in this "sandbox" is a vulnerability in the browser, not some 3rd party plugin.
Put differently, this pypy emulation is no different from the Javascript API that was in your browser already. This isn't a new plugin, just using Javascript to emulate Python through the Pypy interpreter.
My code basically calls int(time.time()) until its value changes, doing i+=1 for every time it did not change (n=10 for every platform (python2/3/pypy/browser)). My browser is Firefox 61, full code here: https://hastebin.com/turenofise.py
But you made me think: indeed, the underlying call could be slower from JS whereas from pypy/python{2,3} it's fast (or vice versa). So I just tested a version where it checks how long ten million iterations take (n=3). Code here: https://hastebin.com/uyuhecabek.py
Since there is no syscall to be made, pypy can do this in compiled code and is blazingly fast (I bet C/assembly isn't much faster there), and the rest seems comparable to the previous estimate: the browser version is 2.25× slower compared to python3 (now 2.43×) and 3.33× slower compared to python2 (now 3.70×).Edit: SO answer explaining the PyPy JIT: https://stackoverflow.com/questions/37377787/what-kind-of-ji...
Running it on OP's website again just to be sure, it now takes 4.9 seconds instead of 5.25, so there is some variance there, but this is still a big difference. This is Firefox as well (see another comment in this subthread), I don't have Chromium installed.
Besides, if calculations are important, you would use numpy.
Here's the code:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
https://johnresig.com/blog/accuracy-of-javascript-time/
It is used by a class taught on Coursera (Introduction to Interactive Programming in Python)
From what I can see:
- PyPy.js benefit: runs faster
- codeskulptor benefit: can use GUI components
So this is a subset of Python or something like that?
Edit: Just checked the site and see it uses PyPy which states -- on their site -- the python version is 3.5.3
a, *b = range(3)
which should be 3.5 i think.
For all other cases, stay in Node or use a lib from a language more suited to WASM compilation. Now, if it's an option between this and a native Node module, that depends on your opinion of Node FFI and native Node modules.
A) Run it as a subprocess
B) Call it over HTTP request/response
C) Use a message broker like AMQP