[Numpy-svn] [numpy/numpy] 355d92: BUG: Add a lock to assert_equal and other testing ...
GitHub
noreply at github.com
Sat Dec 31 16:17:10 EST 2016
Branch: refs/heads/maintenance/1.12.x
Home: https://github.com/numpy/numpy
Commit: 355d92188b7f5ba8cf62c639b6e3ae8cbf19cb90
https://github.com/numpy/numpy/commit/355d92188b7f5ba8cf62c639b6e3ae8cbf19cb90
Author: Sebastian Berg <sebastian at sipsolutions.net>
Date: 2016-12-30 (Fri, 30 Dec 2016)
Changed paths:
M numpy/testing/utils.py
Log Message:
-----------
BUG: Add a lock to assert_equal and other testing functions
This lock prevents unsafe warning filter manipulations during testing
if downstream packages do parallel testing.
Warning filtering is generally not threadsafe in python, this is also
true for `catch_warnings` or `suppress_warinings`. In NumPy 1.12
however, `assert_equal` and the array comparison asserts, use this
to filter out some comparison warnings. Since removing this filter
may also affect downstream projects and skimage (and possibly more)
do parallel manual parallel testing using `assert_equal`, a quick fix
seems to be to lock the less obvious threading trap. Ideally (in
master this is the case), there should simply not be warning filter
logic in the assert functions themself.
While probably not perfectly safe in principle, it is sufficient
in the case of skimage and probably most testing scenarios and the
chance of deadlocks seems very unlikely.
Closes gh-8413
Commit: b0b916ad64f01e2a24c0501ced43f773307d9ee3
https://github.com/numpy/numpy/commit/b0b916ad64f01e2a24c0501ced43f773307d9ee3
Author: Charles Harris <charlesr.harris at gmail.com>
Date: 2016-12-31 (Sat, 31 Dec 2016)
Changed paths:
M numpy/testing/utils.py
Log Message:
-----------
Merge pull request #8427 from seberg/lock_asserts
BUG: Add a lock to assert_equal and other testing functions
Compare: https://github.com/numpy/numpy/compare/3dfd5a52e7be...b0b916ad64f0
More information about the Numpy-svn
mailing list