Tests: Requirements: Scheduled weekly dependency update for week 06

[pyup-bot]

Update pyside6 from 6.2.2.1 to 6.2.3.

The bot wasn't able to find a changelog for this release. Got an idea?

Links

• PyPI: https://pypi.org/project/pyside6
• Homepage: https://www.pyside.org

Update pyqt6 from 6.2.2 to 6.2.3.

The bot wasn't able to find a changelog for this release. Got an idea?

Links

• PyPI: https://pypi.org/project/pyqt6
• Homepage: https://www.riverbankcomputing.com/software/pyqt/

Update pyqt6-qt6 from 6.2.2 to 6.2.3.

The bot wasn't able to find a changelog for this release. Got an idea?

Links

• PyPI: https://pypi.org/project/pyqt6-qt6
• Homepage: https://www.riverbankcomputing.com/software/pyqt/

Update pyqt6-webengine-qt6 from 6.2.2 to 6.2.3.

The bot wasn't able to find a changelog for this release. Got an idea?

Links

• PyPI: https://pypi.org/project/pyqt6-webengine-qt6
• Homepage: https://www.riverbankcomputing.com/software/pyqt/

Update scipy from 1.7.3 to 1.8.0.

Changelog

1.8.0

many new features, numerous bug-fixes, improved test coverage and better
documentation. There have been a number of deprecations and API changes
in this release, which are documented below. All users are encouraged to
upgrade to this release, as there are a large number of bug-fixes and
optimizations. Before upgrading, we recommend that users check that
their own code does not use deprecated SciPy functionality (to do so,
run your code with ``python -Wd`` and check for ``DeprecationWarning`` s).
Our development attention will now shift to bug-fix releases on the
1.8.x branch, and on adding new features on the master branch.

This release requires Python `3.8`+ and NumPy `1.17.3` or greater.

For running on PyPy, PyPy3 `6.0`+ is required.


Highlights of this release
-------------------------

-  A sparse array API has been added for early testing and feedback; this
work is ongoing, and users should expect minor API refinements over
the next few releases.
- The sparse SVD library PROPACK is now vendored with SciPy, and an interface
is exposed via `scipy.sparse.svds` with ``solver='PROPACK'``.
- A new `scipy.stats.sampling` submodule that leverages the ``UNU.RAN`` C
library to sample from arbitrary univariate non-uniform continuous and
discrete distributions
- All namespaces that were private but happened to miss underscores in
their names have been deprecated.

New features
-------------

`scipy.fft` improvements
========================

Added an ``orthogonalize=None`` parameter to the real transforms in `scipy.fft`
which controls whether the modified definition of DCT/DST is used without
changing the overall scaling.

`scipy.fft` backend registration is now smoother, operating with a single
registration call and no longer requiring a context manager.

`scipy.integrate` improvements
==============================

`scipy.integrate.quad_vec` introduces a new optional keyword-only argument,
``args``. ``args`` takes in a tuple of extra arguments if any (default is
``args=()``), which is then internally used to pass into the callable function
(needing these extra arguments) which we wish to integrate.

`scipy.interpolate` improvements
================================

`scipy.interpolate.BSpline` has a new method, ``design_matrix``, which
constructs a design matrix of b-splines in the sparse CSR format.

A new method ``from_cubic`` in ``BSpline`` class allows to convert a
``CubicSpline`` object to ``BSpline`` object.

`scipy.linalg` improvements
===========================

`scipy.linalg` gained three new public array structure investigation functions.
`scipy.linalg.bandwidth` returns information about the bandedness of an array
and can be used to test for triangular structure discovery, while
`scipy.linalg.issymmetric` and `scipy.linalg.ishermitian` test the array for
exact and approximate symmetric/Hermitian structure.

`scipy.optimize` improvements
=============================

`scipy.optimize.check_grad` introduces two new optional keyword only arguments,
``direction`` and ``seed``. ``direction`` can take values, ``'all'`` (default),
in which case all the one hot direction vectors will be used for verifying
the input analytical gradient function and ``'random'``, in which case a
random direction vector will be used for the same purpose. ``seed``
(default is ``None``) can be used for reproducing the return value of
``check_grad`` function. It will be used only when ``direction='random'``.

The `scipy.optimize.minimize` ``TNC`` method has been rewritten to use Cython
bindings. This also fixes an issue with the callback altering the state of the
optimization.

Added optional parameters ``target_accept_rate`` and ``stepwise_factor`` for
adapative step size adjustment in ``basinhopping``.

The ``epsilon`` argument to ``approx_fprime`` is now optional so that it may
have a default value consistent with most other functions in `scipy.optimize`.

`scipy.signal` improvements
===========================

Add ``analog`` argument, default ``False``, to ``zpk2sos``, and add new pairing
option ``'minimal'`` to construct analog and minimal discrete SOS arrays.
``tf2sos`` uses zpk2sos; add ``analog`` argument here as well, and pass it on
to ``zpk2sos``.

``savgol_coeffs`` and ``savgol_filter`` now work for even window lengths.

Added the Chirp Z-transform and Zoom FFT available as `scipy.signal.CZT` and
`scipy.signal.ZoomFFT`.

`scipy.sparse` improvements
===========================

An array API has been added for early testing and feedback; this
work is ongoing, and users should expect minor API refinements over
the next few releases. Please refer to the `scipy.sparse`
docstring for more information.

``maximum_flow`` introduces optional keyword only argument, ``method``
which accepts either, ``'edmonds-karp'`` (Edmonds Karp algorithm) or
``'dinic'`` (Dinic's algorithm). Moreover, ``'dinic'`` is used as default
value for ``method`` which means that Dinic's algorithm is used for computing
maximum flow unless specified. See, the comparison between the supported
algorithms in
`this comment <https://github.com/scipy/scipy/pull/14358#issue-684212523>`_.

Parameters ``atol``, ``btol`` now default to 1e-6 in
`scipy.sparse.linalg.lsmr` to match with default values in
`scipy.sparse.linalg.lsqr`.

Add the Transpose-Free Quasi-Minimal Residual algorithm (TFQMR) for general
nonsingular non-Hermitian linear systems in `scipy.sparse.linalg.tfqmr`.

The sparse SVD library PROPACK is now vendored with SciPy, and an interface is
exposed via `scipy.sparse.svds` with ``solver='PROPACK'``. For some problems,
this may be faster and/or more accurate than the default, ARPACK.

``sparse.linalg`` iterative solvers now have a nonzero initial guess option,
which may be specified as ``x0 = 'Mb'``.

The ``trace`` method has been added for sparse matrices.

`scipy.spatial` improvements
============================

`scipy.spatial.transform.Rotation` now supports item assignment and has a new
``concatenate`` method.

Add `scipy.spatial.distance.kulczynski1` in favour of
`scipy.spatial.distance.kulsinski` which will be deprecated in the next
release.

`scipy.spatial.distance.minkowski` now also supports ``0<p<1``.

`scipy.special` improvements
============================

The new function `scipy.special.log_expit` computes the logarithm of the
logistic sigmoid function. The function is formulated to provide accurate
results for large positive and negative inputs, so it avoids the problems
that would occur in the naive implementation ``log(expit(x))``.

A suite of five new functions for elliptic integrals:
``scipy.special.ellipr{c,d,f,g,j}``. These are the
`Carlson symmetric elliptic integrals <https://dlmf.nist.gov/19.16>`_, which
have computational advantages over the classical Legendre integrals. Previous
versions included some elliptic integrals from the Cephes library
(``scipy.special.ellip{k,km1,kinc,e,einc}``) but was missing the integral of
third kind (Legendre's Pi), which can be evaluated using the new Carlson
functions. The new Carlson elliptic integral functions can be evaluated in the
complex plane, whereas the Cephes library's functions are only defined for
real inputs.

Several defects in `scipy.special.hyp2f1` have been corrected. Approximately
correct values are now returned for ``z`` near ``exp(+-i*pi/3)``, fixing
`8054 <https://github.com/scipy/scipy/issues/8054>`_. Evaluation for such ``z``
is now calculated through a series derived by
`López and Temme (2013) <https://arxiv.org/abs/1306.2046>`_ that converges in
these regions. In addition, degenerate cases with one or more of ``a``, ``b``,
and/or ``c`` a non-positive integer are now handled in a manner consistent with
`mpmath's hyp2f1 implementation <https://mpmath.org/doc/current/functions/hypergeometric.html>`_,
which fixes `7340 <https://github.com/scipy/scipy/issues/7340>`_. These fixes
were made as part of an effort to rewrite the Fortran 77 implementation of
hyp2f1 in Cython piece by piece. This rewriting is now roughly 50% complete.

`scipy.stats` improvements
==========================

`scipy.stats.qmc.LatinHypercube` introduces two new optional keyword-only
arguments, ``optimization`` and ``strength``. ``optimization`` is either
``None`` or ``random-cd``. In the latter, random permutations are performed to
improve the centered discrepancy. ``strength`` is either 1 or 2. 1 corresponds
to the classical LHS while 2 has better sub-projection properties. This
construction is referred to as an orthogonal array based LHS of strength 2.
In both cases, the output is still a LHS.

`scipy.stats.qmc.Halton` is faster as the underlying Van der Corput sequence
was ported to Cython.

The ``alternative`` parameter was added to the ``kendalltau`` and ``somersd``
functions to allow one-sided hypothesis testing. Similarly, the masked
versions of ``skewtest``, ``kurtosistest``, ``ttest_1samp``, ``ttest_ind``,
and ``ttest_rel`` now also have an ``alternative`` parameter.

Add `scipy.stats.gzscore` to calculate the geometrical z score.

Random variate generators to sample from arbitrary univariate non-uniform
continuous and discrete distributions have been added to the new
`scipy.stats.sampling` submodule. Implementations of a C library
`UNU.RAN <http://statmath.wu.ac.at/software/unuran/>`_ are used for
performance. The generators added are:

- TransformedDensityRejection
- DiscreteAliasUrn
- NumericalInversePolynomial
- DiscreteGuideTable
- SimpleRatioUniforms

The ``binned_statistic`` set of functions now have improved performance for
the ``std``, ``min``, ``max``, and ``median`` statistic calculations.

``somersd`` and ``_tau_b`` now have faster Pythran-based implementations.

Some general efficiency improvements to handling of ``nan`` values in
several ``stats`` functions.

Added the Tukey-Kramer test as `scipy.stats.tukey_hsd`.

Improved performance of `scipy.stats.argus` ``rvs`` method.

Added the parameter ``keepdims`` to `scipy.stats.variation` and prevent the
undesirable return of a masked array from the function in some cases.

``permutation_test`` performs an exact or randomized permutation test of a
given statistic on provided data.


Deprecated features
---------------------

Clear split between public and private API
==========================================

SciPy has always documented what its public API consisted of in
:ref:`its API reference docs <scipy-api>`,
however there never was a clear split between public and
private namespaces in the code base. In this release, all namespaces that were
private but happened to miss underscores in their names have been deprecated.
These include (as examples, there are many more):

- ``scipy.signal.spline``
- ``scipy.ndimage.filters``
- ``scipy.ndimage.fourier``
- ``scipy.ndimage.measurements``
- ``scipy.ndimage.morphology``
- ``scipy.ndimage.interpolation``
- ``scipy.sparse.linalg.solve``
- ``scipy.sparse.linalg.eigen``
- ``scipy.sparse.linalg.isolve``

All functions and other objects in these namespaces that were meant to be
public are accessible from their respective public namespace (e.g.
`scipy.signal`). The design principle is that any public object must be
accessible from a single namespace only; there are a few exceptions, mostly for
historical reasons (e.g., ``stats`` and ``stats.distributions`` overlap).
For other libraries aiming to provide a SciPy-compatible API, it is now
unambiguous what namespace structure to follow.  See
`gh-14360 <https://github.com/scipy/scipy/issues/14360>`_ for more details.

Other deprecations
--------------------

``NumericalInverseHermite`` has been deprecated from `scipy.stats` and moved
to the `scipy.stats.sampling` submodule. It now uses the C implementation of
the UNU.RAN library so the result of methods like ``ppf`` may vary slightly.
Parameter ``tol`` has been deprecated and renamed to ``u_resolution``. The
parameter ``max_intervals`` has also been deprecated and will be removed in a
future release of SciPy.


Backwards incompatible changes
----------------------------------

- SciPy has raised the minimum compiler versions to GCC 6.3 on linux and
VS2019 on windows. In particular, this means that SciPy may now use C99 and
C++14 features. For more details see
`here <https://docs.scipy.org/doc/scipy/reference/dev/toolchain.html>`_.
- The result for empty bins for `scipy.stats.binned_statistic` with the builtin
``'std'`` metric is now ``nan``, for consistency with ``np.std``.
- The function `scipy.spatial.distance.wminkowski` has been removed. To achieve
the same results as before, please use the ``minkowski`` distance function
with the (optional) ``w=`` keyword-argument for the given weight.

Other changes
---------------

Some Fortran 77 code was modernized to be compatible with NAG's nagfor Fortran
compiler (see, e.g., `PR 13229 <https://github.com/scipy/scipy/pull/13229>`_).

``threadpoolctl`` may now be used by our test suite to substantially improve
the efficiency of parallel test suite runs.

Authors
---------

* endolith
* adamadanandy +
* akeemlh +
* Anton Akhmerov
* Marvin Albert +
* alegresor +
* Andrew Annex +
* Pantelis Antonoudiou +
* Ross Barnowski +
* Christoph Baumgarten
* Stephen Becker +
* Nickolai Belakovski
* Peter Bell
* berberto +
* Georgii Bocharov +
* Evgeni Burovski
* Matthias Bussonnier
* CJ Carey
* Justin Charlong +
* Dennis Collaris +
* David Cottrell +
* cruyffturn +
* da-woods +
* Anirudh Dagar
* Tiger Du +
* Thomas Duvernay
* Dani El-Ayyass +
* Castedo Ellerman +
* Donnie Erb +
* Andreas Esders-Kopecky +
* Livio F +
* Isuru Fernando
* Evelyn Fitzgerald +
* Sara Fridovich-Keil +
* Mark E Fuller +
* Ralf Gommers
* Kevin Richard Green +
* guiweber +
* Nitish Gupta +
* h-vetinari
* Matt Haberland
* J. Hariharan +
* Charles Harris
* Trever Hines
* Ian Hunt-Isaak +
* ich +
* Itrimel +
* Jan-Hendrik Müller +
* Jebby993 +
* Evan W Jones +
* Nathaniel Jones +
* Jeffrey Kelling +
* Malik Idrees Hasan Khan +
* Sergey B Kirpichev
* Kadatatlu Kishore +
* Andrew Knyazev
* Ravin Kumar +
* Peter Mahler Larsen
* Eric Larson
* Antony Lee
* Gregory R. Lee
* Tim Leslie
* lezcano +
* Xingyu Liu
* Christian Lorentzen
* Lorenzo +
* Smit Lunagariya +
* Lv101Magikarp +
* Yair M +
* Cong Ma
* Lorenzo Maffioli +
* majiang +
* Brian McFee +
* Nicholas McKibben
* John Speed Meyers +
* millivolt9 +
* Jarrod Millman
* Harsh Mishra +
* Boaz Mohar +
* naelsondouglas +
* Andrew Nelson
* Nico Schlömer
* Thomas Nowotny +
* nullptr +
* Teddy Ort +
* Nick Papior
* ParticularMiner +
* Dima Pasechnik
* Tirth Patel
* Matti Picus
* Ilhan Polat
* Adrian Price-Whelan +
* Quentin Barthélemy +
* Sundar R +
* Judah Rand +
* Tyler Reddy
* Renal-Of-Loon +
* Frederic Renner +
* Pamphile Roy
* Bharath Saiguhan +
* Atsushi Sakai
* Eric Schanet +
* Sebastian Wallkötter
* serge-sans-paille
* Reshama Shaikh +
* Namami Shanker
* Walter Simson +
* Gagandeep Singh +
* Leo C. Stein +
* Albert Steppi
* Kai Striega
* Diana Sukhoverkhova
* Søren Fuglede Jørgensen
* Mike Taves
* Ben Thompson +
* Bas van Beek
* Jacob Vanderplas
* Dhruv Vats +
* H. Vetinari +
* Thomas Viehmann +
* Pauli Virtanen
* Vlad +
* Arthur Volant
* Samuel Wallan
* Stefan van der Walt
* Warren Weckesser
* Josh Wilson
* Haoyin Xu +
* Rory Yorke
* Egor Zemlyanoy
* Gang Zhao +
* 赵丰 (Zhao Feng) +

A total of 132 people contributed to this release.
People with a "+" by their names contributed a patch for the first time.
This list of names is automatically generated, and may not be fully complete.

Links

• PyPI: https://pypi.org/project/scipy
• Changelog: https://pyup.io/changelogs/scipy/
• Repo: https://github.com/scipy/scipy/releases
• Homepage: https://www.scipy.org

Update Pillow from 9.0.0 to 9.0.1.

Changelog

9.0.1

------------------

- In show_file, use os.remove to remove temporary images. CVE-2022-24303 6010
[radarhere, hugovk]

- Restrict builtins within lambdas for ImageMath.eval. CVE-2022-22817 6009
[radarhere]

Links

• PyPI: https://pypi.org/project/pillow
• Changelog: https://pyup.io/changelogs/pillow/
• Homepage: https://python-pillow.org

Update numpy from 1.22.1 to 1.22.2.

The bot wasn't able to find a changelog for this release. Got an idea?

Links

• PyPI: https://pypi.org/project/numpy
• Homepage: https://www.numpy.org

[bwoodsend]

Those are some seriously weird scipy wheels for macOS. They have both universal2 and separate architecture variants. Both the arm64 slice of the universal2 wheel and the arm64 wheel targets macOS >= 12 leaving macOS M1 Big Surs to compile from source. Inside the universal2 there is a mixture of fat and thin dylibs including one i386 slice:

> for file in scipy/.
    printf '%s\t%s\n' $file (llvm-lipo -archs $file)
end
scipy/.dylibs/libgcc_s.1.dylib		x86_64 i386 
scipy/.dylibs/libgcc_s.2.dylib		arm64 
scipy/.dylibs/libgfortran.3.dylib	x86_64 
scipy/.dylibs/libgfortran.5.dylib	arm64 
scipy/.dylibs/libopenblas.0.dylib	x86_64 arm64 
scipy/.dylibs/libquadmath.0.dylib	x86_64 

Surely this isn't intentional...

[bwoodsend]

I've gone and asked them (scipy/scipy#15539). If it turns out that it was deliberate then I think that it would be better to make the scipy hook check and filter by the architecture of each dylib instead of generalising binary_to_target_arch() to silently ignore incorrect thin binaries. Whilst M1 CI/CD still doesn't exist, that assertion is probably all that's keeping applications with missing arm64 slices from being released blindly since there is no way to test them without M1 hardware.

[rokm]

What worries me is that the extensions themselves seem to be universal2, but they are linked against the x86_64 version of the library, e.g.:

$ lipo -archs venv/lib/python3.9/site-packages/scipy/linalg/cython_blas.cpython-39-darwin.so 
x86_64 arm64

$ otool -L venv/lib/python3.9/site-packages/scipy/linalg/cython_blas.cpython-39-darwin.so 
venv/lib/python3.9/site-packages/scipy/linalg/cython_blas.cpython-39-darwin.so:
	@loader_path/../.dylibs/libopenblas.0.dylib (compatibility version 0.0.0, current version 0.0.0)
	@loader_path/../.dylibs/libgfortran.3.dylib (compatibility version 4.0.0, current version 4.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
	@loader_path/../.dylibs/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	@loader_path/../.dylibs/libquadmath.0.dylib (compatibility version 1.0.0, current version 1.0.0)

So the only way I imagine this might load arm64 libraries when running on M1 is if there's some ctypes or equivalent trick somewhere that "preloads" the arm64 variants when necessary...

[bwoodsend]

Turns out that the lack of Big Sur support is deliberate due to some messy segfaulting, libquadmath.0.dylib doesn't support arm64 but is an optional dependency which is why it only has an x86_64 slice and that i386 slice is an accident but is deemed a fairly harmless one.

[bwoodsend]

What worries me is that the extensions themselves seem to be universal2, but they are linked against the x86_64 version of the library, e.g.:

Do you want to ask them that too? They've been very quick to respond on scipy/scipy#15539.

[bwoodsend]

I don't suppose it's possible for two slices of a fat executable to be linked to different dependencies? And then maybe otool simply checks the first slice? What happens if you extract only the arm64 slice then otool that?

[rokm]

Ah, of course, different slices are linked against different libraries:

$ otool -L -arch x86_64 venv/lib/python3.9/site-packages/scipy/linalg/cython_blas.cpython-39-darwin.so 
venv/lib/python3.9/site-packages/scipy/linalg/cython_blas.cpython-39-darwin.so:
	@loader_path/../.dylibs/libopenblas.0.dylib (compatibility version 0.0.0, current version 0.0.0)
	@loader_path/../.dylibs/libgfortran.3.dylib (compatibility version 4.0.0, current version 4.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
	@loader_path/../.dylibs/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	@loader_path/../.dylibs/libquadmath.0.dylib (compatibility version 1.0.0, current version 1.0.0)

$ otool -L -arch arm64 venv/lib/python3.9/site-packages/scipy/linalg/cython_blas.cpython-39-darwin.so 
venv/lib/python3.9/site-packages/scipy/linalg/cython_blas.cpython-39-darwin.so:
	@loader_path/../.dylibs/libopenblas.0.dylib (compatibility version 0.0.0, current version 0.0.0)
	@loader_path/../.dylibs/libgfortran.5.dylib (compatibility version 6.0.0, current version 6.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1)

This means our binary analysis is faulty, because it probably ended up pulling in all dependencies from all arches. Which would be a correct thing to do in universal2 target mode (but then we'd need to kill the slice arch verification), but not in the single-arch one (where we'd need to scan only dependencies of the target slice).

[rokm]

Suppose we drop the scipy update for now, and repin it once we have this sorted out?