[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