Hi Steve, On 30/11/2018, Steve Dower <steve.do...@python.org> wrote: > On 29Nov2018 2206, Armin Rigo wrote: >> On Thu, 29 Nov 2018 at 18:19, Steve Dower <steve.do...@python.org> wrote: >>> quo. We continue to not be able to change CPython internals at all, >>> since that will break people using option B. >> >> No? That will only break users if they only have an option-B >> ``foo.cpython-318m-x86_64-linux-gnu.so``, no option-A .so and no >> source code, and want to run it elsewhere than CPython 3.18. That's >> the same as today. If you want option-B .so for N versions of >> CPython, recompile the source code N times. >> >> Just to be clear, if done correctly there should be no need for >> #ifdefs in the source code of the extension module. > > The problem is that if option B remains as compatible as it is today, we > can't make option A faster enough to be attractive. The marketing pitch > for this looks like: "rewrite all your existing code to be slower but > works with PyPy, or don't rewrite your existing code and it'll be > fastest with CPython and won't break in the future". This is status quo > (where option A today is something like CFFI or Cython), and we can > already see how many people have made the switch (FWIW, I totally prefer > Cython over pure C for my own projects :) ). > > My proposed marketing pitch is: "rewrite your existing code to be > forward-compatible today and faster in the future without more work, or > be prepared to rewrite/update your source code for each CPython release > to remain compatible with the low level API". > (...)
Discussing marketing pitches on python-dev is not one of my favorite past-times, so I'll excuse myself out of this conversation. Instead, I might try to implement the basics, check out the performance on CPython and on PyPy, and seek out interest---I'm thinking about Cython, for example, which might relatively easily be adapted to generate that kind of code. This might be a solution for the poor performance of Cython on PyPy... If everything works out, maybe I'll come back here at some point, with the argument "the CPython C API is blocking CPython from evolution more and more? Here's one possible path forward." A bientôt, Armin. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com