Le mer. 12 sept. 2018 à 19:39, Neil Schemenauer firstname.lastname@example.org a écrit :
After you do it, merging between cpython versions becomes essentially impossible since you are changing like 50% of the lines of source code. So, I can imagine that some core developers would resist the change. I think even though it is painful, it is the correct thing to do. If you want to allow Python to be embedded properly (e.g. for game scripting), you have to do it. So, I think we should plan to "bit the bullet" and have a "flag day". I think Python is losing to Lua in these applications because embedding Python doesn't work properly.
It's really too early to discuss modifying the upstream code.
But you are asking, so let me reply :-) If we find a consensus of the right level of breaking changes, if we agree on performance, if we agree on the way to opt-in for the API, if we have a proper tooling to migrate to the new C API, if we provide tooling to use the new C API on Python 3.7 and older, we can start discussing how to merge these changes into CPython upstream.
My long term plan is to make most changes conditional using a C define, and only enable this flag using a ./configure option. We would provide two runtimes: "python3.8" compiled with default options and "python3.8-exp" (or another more funky name) which enables the new cool optimizations but only supports the new C API.
"python3.8" will continue to support the full unmodified old C API, in addition to supporting the new C API.