I would prefer to revert PyCode_New() API (to Python 3.7 and older API), and add a *new* function for positional-only arguments.


> I have created PR13959 in case we decide to go with the PyCode_NewEx path.

I dislike "Ex" suffix. What will be next name? Ex2? NewEx?

I prefer "With" naming.

I suggest: PyCode_NewWithPosArgs(). IMHO it's way more explicit when you opt-in for this new function ;-)

--

PyCode_New() was broken 8 times in the history of Python :-)
https://bugs.python.org/issue37032#msg343377

It seems like more people are unhappy with this backward incompatible change, because Python popularity is still growing. It's a good sign of the health of time :-)

-- 

> +1. You already broke backwards compatibility once in beta1, no need to do it again in beta2.

It's not this easy.

This issue mostly impact projects using Cython. For practical reasons, projects include C files generated by Cython (to avoid Cython dependency to install the project). Cython 0.29.8 is the first version supporting Python 3.8 (new PyCode_New API) was only released two weeks ago.

Right now, I guess that almost all, if not all, tarballs on PyPI on projects using Cython still include C code only compatible with Python 3.7 (old PyCode_New API).

There are 183k projets on PyPI. I would prefer to not have to have to manually regenerate the C code they include to support the new PyCode_New() API.

We are still at beta stage. The role of beta releases is to detect backward incompatible changes like that.

I'm in favor of reverting PyCode_New() API and add a new function for the very few people who care about building manually a code object with positional-only arguments.

It's just a practical move to not break projects on PyPI.

Please, synchronize with Cython to make sure that we can get a Cython release soon after beta2 with will emit code working on all Python version. Maybe the workaround for Python 3.8 alpha1 .. 3.8 beta1 can be simply removed from Cython?