On Wed, 12 Sep 2018 at 11:02 Barry Warsaw email@example.com wrote:
On Sep 12, 2018, at 10:39, Neil Schemenauer firstname.lastname@example.org wrote:
As I said to you early in the week, you are a brave person to try to tackle this C-API project.
Agreed, and as you allude to, the social aspects are at least as challenging as the technical ones.
You can have two sets of APIs. One set has ctx as the first argument of every API call. You make a second "easy" set that builds on the first set and uses a global as the ctx argument. This second set could be compatible with the current API. The painful part is that all CPython internals must use the first set of APIs (explicitly pass ctx). Something like Coccinelle could do the hard work.
I agree with this general approach as well.
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.
+1 from me as well to this general plan. I’m hoping that Victor’s port can prove that it’s feasible and give us high confidence that it can eventually lead to improved performance, embeddability, etc. I wonder whether this will be ready for 3.8, and if not, if there is some groundwork we can lay in 3.8 that won’t be as radical, but will make the flag day easier for 3.9 or 4.0 or whatever comes after that.
I think we should just operate under the assumption that this project is going to be big enough that this is a Py4K project. There's no need to rush and I wouldn't want any release deadline to make people feel rushed.