Package: python3-scipy Followup-For: Bug #1020561 Confirmed that tests still pass (amd64) if python3-pythran is forcibly not installed.
Making an audit of where pythran is actually used (in v.10), at runtime that is: scipy/interpolate _rbfinterp_pythran.py see also setup.py, meson.build scipy/optimize _group_columns.py used by ._numdiff.group_columns scipy/linalg _matfuncs_sqrtm_triu.py (not clear that this is used. meson.build refers to the cython variant _matfuncs_sqrtm_triu.pyx) scipy/stats _stats_pythran.py _hypotests.py _stats_mstats_common.py scipy/signal _spectral.py The pythran definitions are supplied as # pythran export ... So they are enclosed in comments. If pythran is not present then the definition is handled as a normal comment, i.e. ignored. At build time python extensions are built using these definitions via meson.build e.g. interpolate/_rbfinterp_pythran.cpython-39-x86_64-linux-gnu.so But once these a built pythran is not needed to rebuild them. This does confuse me, I thought the advantage of pythran was a jit optimisation at runtime. In this case pythran just provides an automated means of running cython, rather than an optimisation to the runtime cpu. Not clear then what the advantage of optimize/_group_columns.py is over optimize/_group_columns.pyx Perhaps the pythran variant is better tuned. So, what is pythran is doing is essentially replacing the .py file with a .so library. It's an ahead-of-time compiler, not a just-in-time compiler. Conclusion:, we want to use pythran at build time. But there's no further reason to depend on it at runtime (not even as Recommends)
