On 2019-05-31, Simon Cross wrote: > As the maintainer of Genshi, one the libraries affected by the CodeType and > similar changes, I thought I could add a users perspective to the > discussion: [...]
Thanks. I think this change to PyCode_New() could have been handled a bit better. Couldn't we introduce a new CPP define that enables the revised API of PyCode_New()? For 3.8 extensions, they would get the backwards compatible API (and a warning) unless they set the define. For 3.9, we would enable the new API by default. That gives 3rd party extensions one release cycle to catch up to the change. Perhaps something similar could be done for CodeType called from within Python code. In this case, it seems that introducing a new API like PyCode_NewEx() is not the way. However, just changing an API like that is not very friendly to 3rd party extensions, even if we don't claim it is a stable API. For me, change to PyCode_New() means that I can't test the 3.8.0b1 because the 3rd party extensions I rely on don't compile with it. Normally I try to test my application code with the latest alpha and beta releases. It would be great if we had a system that did CI testing with the top PyPI modules. E.g. pull the latest versions of the top 100 PyPI modules and test them with the latest CPython branch. With that, at least we would know what the fallout would be from some incompatible CPython change. Setting that system up would be a fair amounnt of work but I suspect the PSF could fund someone who puts together a plan to do it. Such a system would be even more useful if we start moving stuff out of stdlib into PyPI. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/2A4LAPCESAMJCPVCAQNEWYG2UC2BFKUU/
