This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients jdemeyer, ncoghlan, petr.viktorin, scoder, steve.dower, vstinner
Date 2019-06-18.16:27:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1560875260.28.0.103068966186.issue37250@roundup.psfhosted.org>
In-reply-to
Content
Steve Dower:
> * Pre-generated Cython .c files can be easily regenerated, and given their use of low-level and internal APIs would cause undue compatibility burden on CPython if we were to treat everything it uses as public stable API

It seems like you missed the whole point of this issue. No, it's not "easy" to regenerate these Cython .c files.

Let's pick a random module on PyPI... numpy.

$ python3.8 -m venv env
$ env/bin/python -m pip install numpy
...
Collecting numpy
  Downloading https://files.pythonhosted.org/packages/d3/4b/f9f4b96c0b1ba43d28a5bdc4b64f0b9d3fbcf31313a51bc766942866a7c7/numpy-1.16.4.zip (5.1MB)
...
    numpy/random/mtrand/mtrand.c:311:11: erreur: trop peu d'arguments pour la fonction « PyCode_New »
      311 |           PyCode_New(a, k, l, s, f, code, c, n, v, fv, cell, fn, name, fline, lnos)
          |           ^~~~~~~~~~


So right now, 16 days after Cython 0.29.10 release, numpy cannot be installed on Python 3.8 because of bpo-37221. But bpo-37221 is going to revert PyCode_New() API, and then the install will fail at "tp_print = NULL".

numpy is like one of the most popular C extensions on PyPI. But there are 184k projects on PyPI: some of them of Cython.

Some old projects on PyPI will never be updated anymore, but there are likely applications in applications which rely on them. This problem is very common.

Random example: setuptools is another top module on PyPI and it vendors html5lib. But html5lib didn't get a release for 1 year 1/2. html5lib emits a deprecation warning which now blocks bpo-37324 ("collections: remove deprecated aliases to ABC classes").

--

This issue is a practical problem: tons of projects on PyPI are currently broken on Python 3.8 and it will take *years* to update all of them.

IMHO we should reintroduce tp_print just to not break all these projects. 8 bytes per PyTypeObject is nothing compared to annoyance of issues introduced by tp_print removal.

--

Yes, I know that tp_print was deprecated for 10 years and it never emitted any deprecation warning. And people don't pay attention to warnings until it becomes a hard error...
History
Date User Action Args
2019-06-18 16:27:40vstinnersetrecipients: + vstinner, ncoghlan, scoder, petr.viktorin, jdemeyer, steve.dower
2019-06-18 16:27:40vstinnersetmessageid: <1560875260.28.0.103068966186.issue37250@roundup.psfhosted.org>
2019-06-18 16:27:40vstinnerlinkissue37250 messages
2019-06-18 16:27:39vstinnercreate