391–400 of 553 posts
Earlier quoted context omitted.
Disregarding the fact that python is an awful programming language for anthing other than jupyter notebooks
Another one that hasn't seen UNIX scripting in shell languages or Perl, Apache modules, before Python came to be.
Earlier quoted context omitted.
There has been so much progress in Julia’s startup performance in the past “few years” that someone’s qualitative impressions from several major releases before the current one are of limited relevance.
You're making this about Julia despite my repeated statements to the contrary. Please reread what I've written, you aren't responding to the actual point I've made twice now. A reminder: I'm talking specifically about my outlook on the future of Python, vis a vis my historical experience with how other JIT languages have developed. If you wanted to rebut this, you'd need to argue that Julia has always been awesome an…
But your assessment of the other language you mentioned is several years out of date and made largely irrelevant by the fast pace of progress. Therefore your conclusions about the probable future of Python, which may be correct, nevertheless do not follow.
The article describes that the new JIT is a "copy-and-patch JIT" (I've previously heard this called a "splat JIT"). This is a relatively simple JIT architecture where you have essentially pre-compiled blobs of machine code for each interpreter instruction that you patch immediate arguments into by copying over them. I once wrote an article about very simple JITs, and the first example in my article uses this style: h…
»LuaJIT is undoubtedly a "full" JIT compiler.« Yes, and it's practically unmaintained. Pull requests to add support for various architectures have remained largely unanswered, including RISC-V.
Earlier quoted context omitted.
This is happening mostly because Guido left, right? The take that CPython should be a reference implementation and thus slow always aggravated me (because, see, no other implementation can compete because every package depends on CPython kirks, in such a way that we're now removing the GIL of CPython rather than migrating to Pypy for example)
Guido is still involved, but he's no longer the BDFL.
[1]: https://en.wikipedia.org/wiki/Benevolent_dictator_for_life
I love Python and use it for everything other than web development. One reason is performance. So if Python has a faster future ahead of it: Hurray! The other reason is that the Python ecosystem moved away from stateless requests like CGI or mod_php use and now is completely set on long running processes. Does this still mean you have to restart your local web application after any change you made to it? I heard that…
All of the popular frameworks automatically reload. It’s not instantaneous but with e.g. Django it was less than the time I needed to switch windows a decade ago and it hadn’t gotten worse. If you’re used to things like NextJS it will likely be noticeably faster.
I love Python and use it for everything other than web development. One reason is performance. So if Python has a faster future ahead of it: Hurray! The other reason is that the Python ecosystem moved away from stateless requests like CGI or mod_php use and now is completely set on long running processes. Does this still mean you have to restart your local web application after any change you made to it? I heard that…
The long-running process is a WSGI/ASGI process that handles spawning the actual code, similar to CGI. The benefit is that it can handle how it spawns the request workers via multiple runtimes, process/threads, etc. It's similar to CGI but instead of nginx handling it, it's a special program that specializes in the different options for python specifically.
> Does this still mean you have to restart your local web application after any change you made to it? I heard that some developers automate that, so that everytime they save a file, the web application is restarted. That seems pretty expensive in terms of resource consumption. And complex as you would have to run some kind of watcher process which handles watching your files and restarting the application?
Only for development!
To update your code in production you first deploy the new code onto the machine, and then you tell the WSGI/ASGI such as Gunicorn to reload. This will cause it to use the new code for new request, without killing current requests.
It's a graceful reload, with no file watching needed. Just a "systemctl reload gunicorn"
Earlier quoted context omitted.
I'd love to see it eat JavaScript and Java for back-end code. But I doubt that's going to ever happen.
I like python but I would never choose it for anything more than trivial on the backend. I want to know what types are being passed around from one middleware function to the next. Yes python has annotations but that’s not enough.
Earlier quoted context omitted.
Copy and patch is a variant of QEMU's original "dyngen" backend by Fabrice Bellard[1][2], with more help from the compiler to avoid the maintainability issues that ultimately led QEMU to use a custom code generator. [1] https://www.usenix.org/legacy/event/usenix05/tech/freenix/fu... [2] https://review.gerrithub.io/plugins/gitiles/spdk/qemu/+/5a24...
Ultimately, most good ideas were first implemented by Fabrice Bellard.
It's interesting to see these 2-9% improvements from version to version. They are always talked about with disappointment, as if they are too small, but they also keep coming, with each version being faster than the previous one. I prefer a steady 10% per version over breaking things because you are hoping for bigger numbers. Those percentages add up!
Someone please compare 3.13 to 2.3! I’d love to see how far we’ve come.
FWIW, the most recent changelog is at https://docs.python.org/3.13/whatsnew/3.13.html
Earlier quoted context omitted.
Copy and patch is a variant of QEMU's original "dyngen" backend by Fabrice Bellard[1][2], with more help from the compiler to avoid the maintainability issues that ultimately led QEMU to use a custom code generator. [1] https://www.usenix.org/legacy/event/usenix05/tech/freenix/fu... [2] https://review.gerrithub.io/plugins/gitiles/spdk/qemu/+/5a24...
Ultimately, most good ideas were first implemented by Fabrice Bellard.