Petr Viktorin <encu...@gmail.com> added the comment:
> scientific projects that depend on it may lag longer as rebuilds and releases > will need to happen on PyPI, conda, and conda-forge. Keep in mind that binary artifacts (wheels, Conda/distro packages) should not be affected. They need to be re-built for Python 3.8 *either way*, because the ABI changed. The only artifacts that putting tp_print back in helps are sdists that include pre-generated Cython output, plus possibly projects that pin Cython to an older version. Specifically, for any platform without a C compiler installed, users aren't helped by putting tp_print back in. So: (1) Status-quo (keep everything as is in 3.8b1): - binary/compiled distributions need to be re-built (*1) - sdists need to be re-generated with an up-to-date Cython (*2) - projects that pin Cython need to update it. + pure source distributions (where compiling involves running Cython) works as before (*3) + type objects do not waste memory + Cython can implement vectorcall optimizations for past Python versions (before 3.8) (2) Apply PR 14193: - binary/compiled distributions still need to be re-built (*1) + sdists DO NOT need to be re-generated (*2) + projects that pin Cython DO NOT need to update it. + pure source distributions (where compiling involves running Cython) works as before (*3) - type objects get 8 bytes larger + Cython can implement vectorcall optimizations for past Python versions (before 3.8) (3) Put back tp_print the way it was in 3.7: - binary/compiled distributions still need to be re-built (*1) + sdists DO NOT need to be re-generated (*2) + projects that pin Cython DO NOT need to update it. + pure source distributions (where compiling involves running Cython) works as before (*3) - type objects get 8 bytes larger - Cython can NOT implement vectorcall optimizations for past (pre-3.8) Python versions *1: applicable to most wheel consumers, conda users, etc. *2: applicable to sdist consumers with a compiler *3: should be applicable to Conda/Fedora/Debian/... packagers (not so much end users) > Is four months really an unreasonable timeline? I thought most of these > packages released more frequently than CPython. Note that maintainers of these packages need to take an action (build wheels) anyway to support Python 3.8 (on compiler-less platforms). They need to test, and ideally even read "Porting to Python 3.8" and adjust the code. Is re-generating Cython output, and bumping the version, too much of an *added* burden here? If a project doesn't release 3.8 wheels by Python 3.8.0rc1, we don't get feedback on it from PyPI users (but Conda & Linux distros should be unaffected, if they run Cython on build). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue37250> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
