3 ms·
From a language design perspective I don't think there's much in the way of making up this ground. The hard part is not breaking any existing modules written in
by gravypod 5y ago
From a language design perspective I don't think there's much in the way of making up this ground. The hard part is not breaking any existing modules written in C/C++/Rust/etc that depend on the cpython ABI (memory layout and calling conventions of the runtime's implementation). There are jit compilers for python like pypy which are very fast (>5x they're attempting to gain here) but they often break things like numpy that have a lot of native modules.
- londons_explore 5y agoSounds pretty straightforward to get great speedups where no modules are used, and just make module calls slow (ie. you reconstruct the data structures the module will need on any entry to the module). Then release a new 'fast' module API, and all the performance critical modules will soon move over.
- gravypod 5y agoIt might sound easy but that would be a critical component of such a rewrite. Python's standard library is implemented using the same API so much of that would need to be rewritten. You then have the risk of introducing bugs, etc. This post is doing something similar. They're rewriting the internal implementation through progressive refactoring and will then look into more long term incompatible changes that can be wrapped in a translation layer. These projects are difficult as a lot of python code exists in the world and a minor change in behavior can have large unintended consequences due to Hyrum's law.