
On Tue, Jun 16, 2020 at 9:30 PM Victor Stinner <vstinner@python.org> wrote:
Le mar. 16 juin 2020 à 10:42, Inada Naoki <songofacandy@gmail.com> a écrit :
Hmm, Is there any chance to add DeprecationWarning in Python 3.9?
In my experience, more and more projects are running their test suite with -Werror, which is a good thing. Introducing a new warning is likely to "break" many of these projects. For example, in Fedora, we run the test suite when we build a package. If a test fails, the package build fails and we have to decide to either ignore the failing tests (not good) or find a solution to repair the tests (update the code base to new C API functions).
But Python 3.9 is still in beta phase and we have enough time to get feedback. If the new warning is unacceptable breakage, we can remove it in RC phase.
It is an interesting idea, but I think it is too complex. Fixing all packages in the PyPI would be a better approach.
It's not the first time that we have to take such decision. "Fixing all PyPI packages" is not possible. Python core developers are limited are so we can only port a very low number of packages. Breaking packages on purpose force developers to upgrade their code base, it should work better than deprecation warnings. But it is likely to make some people unhappy.
OK, My terminology was wrong. Not all, but almost of living packages. * This change doesn't affect to pure Python packages. * Most of the rest uses Cython. Since I already report an issue to Cython, regenerating with new Cython release fixes them. * Most of the rest support PEP 393 already. So I expect only few percents of active packages will be affected. This is a list of use of deprecated APIs from the top 4000 packages, except PyArg_ParseTuple(AndKeywords). Files generated by Cython are excluded. But most of them are false positives yet (e.g. in `#if PY2`). https://github.com/methane/notes/blob/master/2020/wchar-cache/deprecated-use I have filed some issues and sent some pull requests already after I created this thread.
Having a separated hash table would prevent to break many PyPI packages by continuing to provide the backward compatibility. We can even consider to disable it by default, but provide a temporary option to opt-in for backward compatibility. For example, "python3.10 -X unicode_compat".
I proposed sys.set_python_compat_version(version) in the rejected PEP 606, but this PEP was too broad: https://www.python.org/dev/peps/pep-0606/
The question is if it's worth it to pay the maintenance burden on the Python side, or to drop backward compatibility if it's "too expensive".
I understood that your first motivation is to reduce PyASCIObject structure size. Using a hash table, the overhead would only be paid by users of the deprecated functions. But it requires to keep the code and so continue to maintain it. Maybe I missed some drawbacks.
Memory usage is the most important motivation. But runtime cost of PyUnicode_READY and maintenance cost of legacy unicode matters too. I will reconsider your idea. But I still feel that helping many third parties is the most constructive way. Regards, -- Inada Naoki <songofacandy@gmail.com>