[SciPy-Dev] merging optional Pythran support soon

[Ralf Gommers]

Hi all,

https://github.com/scipy/scipy/pull/8306 adds Pythran support to
scipy.signal.max_len_seq. It's optional, so one can set an env var to keep
using the Cython version instead. I plan to merge that soon, now that we're
at the beginning of a release cycle, so we can get some real feedback. Then
if all goes well we can decide to keep it and expand its usage, and if
there are showstoppers we can revert before the 1.7.x branch split.

The first time this was proposed was already 3 years ago:
https://mail.python.org/pipermail/scipy-dev/2018-January/022325.html. As a
reminder, Pythran is an ahead-of-time compiler, taking pure Python code
with some type comments to generate C++, which then gets compiled the
regular way. Its advantages over Cython are:

- pure Python rather than a separate language, so easier to use
- generated source code ~100x shorter
- generated shared libraries ~10x smaller
- on average faster

The main concern I think is Pythran's maturity (which could be okay,
getting some data will be nice) and that it has a bus factor of one (which
isn't that different from Cython).

All CI currently passes, including on Windows, aarch64, and ppc64le. It's
not unlikely that we'll find some other hiccup (e.g. AIX, PyPy), but so far
it looks pretty good so it'd be nice to get some real-world experience with
it.

And to preempt the obvious question: no we don't need to compare with
Numba. That situation didn't change from last time we discussed it; Numba
is a heavy and fragile runtime dependency, and supporting libraries like
SciPy isn't Numba's core focus. I also checked in with Stan Seibert (Numba
core dev) recently, and he agreed with that assessment.

Please have a look at the PR and comment on it or here if there's something
concerning.

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.python.org/pipermail/scipy-dev/attachments/20201226/24d371be/attachment.html>