Numpy: 時々、supress_warningsはその属性の1つを見逃します

うーん、少し奇妙です。 skimageテストで進行中の（奇妙な）スレッドはありますか？ 警告処理はPythonではスレッドセーフではないため、これは警告テストをかなりひどく壊します。 これが他にどのように発生するかを確認するのは少し難しいですが、テストが実行する正確なコードを確認する必要があります。

assert_warnsかそこらがないので、ここにあると思います。 生きているのはsuppress_warningsつの_orig_showが定義されていないのは、コンテキストがすでに終了している場合にのみ可能であるということです。 その時点で、 warnings.showwarningはすでに古い値にリセットされているはずです。

もちろん、スレッドがある場合は、警告全体が機能しなくなります。 例えば：

thread1：警告コンテキストに入ります->通常の警告印刷を置き換えます
thread2：警告コンテキストに入ります-> thread1警告ハンドラーを置き換えます
thread1：警告コンテキストを終了します->通常の警告印刷にリセットします
thread2：警告コンテキストが存在します-> thread1の警告ハンドラーにリセットします-> kaboom。

ところで。 「skimageの__warning_registry__ものの後でクリーンアップしてみてください。抑制警告は、同様の問題を解決しようとする（そして他のいくつかのものを追加する）コンテキストマネージャーであり、興味深い場合とそうでない場合があります。

Debian用のskimageをビルドしようとしたときに問題が発生しましたが、ここではわかりません。 ただし、scikit-image / scikit-image＃2412を開いて参加させました。

完全を期すために：時々、skimageを使用せずにスタックトレースを取得することもあります。

ERROR: test suite for <module 'skimage.transform.tests' from '/build/skimage-0.12.3/debian/tmp/usr/lib/python3/dist-packages/skimage/transform/tests/__init__.py'>
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/suite.py", line 229, in run
    self.tearDown()
  File "/usr/lib/python3/dist-packages/nose/suite.py", line 352, in tearDown
    self.teardownContext(ancestor)
  File "/usr/lib/python3/dist-packages/nose/suite.py", line 368, in teardownContext
    try_run(context, names)
  File "/usr/lib/python3/dist-packages/nose/util.py", line 453, in try_run
    inspect.getargspec(func)
  File "/usr/lib/python3.5/inspect.py", line 1040, in getargspec
    stacklevel=2)
  File "/usr/lib/python3/dist-packages/numpy/testing/utils.py", line 2199, in _showwarning
    self._orig_show(message, category, filename, lineno,
AttributeError: 'suppress_warnings' object has no attribute '_orig_show'

どのバージョンのpython、numpyなどをコンパイルしていますか？

Numpy 1.12〜RC〜ベータ1、Python2.7および3.5
（申し訳ありませんが、私の間違い：RCをまだチェックしていません）

うーん、私は混乱しています....なぜスレッドの問題が発生するのかわかりませんが、競合状態またはcatch_warningようなもの（を含む）の誤ったネストなしで発生するこのエラーを実際に理解することはできませんsuppress_warning ）。

また、常に発生するとは限らないため、競合状態だと思います。 まったく同じ環境でビルドを2回実行すると、問題が別の場所で発生します（またはまったく発生しません）。

@oleboleテストスーツをどの程度正確に実行していますか？

テストスイートからコピー：

#!/bin/sh
set -efu

pys="$(pyversions -rv 2>/dev/null)"
pkgbuild=${pkgbuild:-no}

srcdir=$PWD

for py in $pys; do
    echo "=== python$py ==="
    if [ "$pkgbuild" = "yes" ]; then
        export PYTHONPATH="$srcdir/debian/tmp/usr/lib/python$py/dist-packages"
        cd "$srcdir/build/"
    else
        cd "$ADTTMP"
    fi

    xvfb-run -a python$py /usr/bin/nosetests -s -v --exclude test_tools.py skimage 2>&1
done

テストはX11環境で実行する必要があるため、 xvfb-runがあります。

うーん、鼻がモジュールをテストし始めたときにボンネットの下で正確に何が起こるか知っている人はいますか？ 鼻は私を混乱させます、そしてなぜそれが警告をいじり回してしまうのか分かりません...またはそれは結局警告を抑制することのバグですが、実際にはそれを見ることができませんね。

私のnosetestsのmanページには、

       --processes=NUM
              Spread  test run among this many processes. Set a number equal to the number of processors or cores in your machine for best results. Pass a negative
              number to have the number of processes automatically set to the number of cores. Passing 0 means to disable parallel testing.  Default  is  0  unless
              NOSE_PROCESSES is set. [NOSE_PROCESSES]

デフォルトでは並列テストはないようです。 少なくとも、競合状態はそこにあるべきではありません。

ガベージコレクションに基づいて、noseがこのteardownContextを実行する可能性はほとんどありませんか？！

いいえ、私はおそらくばかげています。 抑制警告コンテキストは、属性を削除する前にwarnings.showwarningリセットするため、gcが起動しても、他に何かが行われなければ実際には何も作成できないことを疑ってください。 他に何がわからなかった:)。

skimage-0.9.3で33個のエラーが発生しました。ほとんどがPILまたはインデックス作成によるものですが、抑制に関するエラーはありません。 他のすべてのエラーにどのように対処しますか？

@charrisこの問題は、0.9.3ではなく0.12.3で報告されています。 :)

OK、ついにそれをアップストリームからプルダウンしました。今では39のエラーと大量の非推奨です。 警告のほとんどは、テストがWaylandではなくQTで実行されていると見なしているためと思われますが、ここでは構成の問題である可能性があります。 また、次のようにテストを実行する必要があります

python -c'import skimage; skimage.test()'

nosetestsはまったく機能しないため。

非推奨は正常です。 廃止が予想される場合でも、古いAPIを引き続きチェックします。 エラーについては、正常ではありません。 （scikit-image）バグトラッカーで報告していただけませんか？

@sciuntoドキュメントでは、ローカルでテストするための手順を使用できます。

はい、同じ場所にあります。 テストは

def test_vectorized_integrate():
    r0 = np.array([12, 0, 0, 10, 0, 10, 30])
    c0 = np.array([10, 0, 10, 0, 0, 10, 31])
    r1 = np.array([23, 19, 19, 19, 0, 10, 49])
    c1 = np.array([19, 19, 19, 19, 0, 10, 49])

    expected = np.array([x[12:24, 10:20].sum(),
                         x[:20, :20].sum(),
                         x[:20, 10:20].sum(),
                         x[10:20, :20].sum(),
                         x[0,0],
                         x[10, 10],
                         x[30:, 31:].sum()])
    start_pts = [(r0[i], c0[i]) for i in range(len(r0))]
    end_pts = [(r1[i], c1[i]) for i in range(len(r0))]
    assert_equal(expected, integrate(s, r0, c0, r1, c1))  # test deprecated
    assert_equal(expected, integrate(s, start_pts, end_pts))

# test deprecatedコメントは、おそらくテストに修正が必要であることを示唆していますが、それでもsuppress_warningsはより正常に失敗するはずです。

もう少し情報を

$ python skimage/transform/tests/test_integral.py

NumPy run_module_suiteしているものは失敗していないようですが、警告を発します

======================================================================
ERROR: skimage.transform.tests.test_integral.test_vectorized_integrate
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
    self.test(*self.arg)
  File "/home/charris/Workspace/scikit-image/skimage/transform/tests/test_integral.py", line 46, in test_vectorized_integrate
    assert_equal(expected, integrate(s, r0, c0, r1, c1))  # test deprecated
  File "/home/charris/Workspace/scikit-image/skimage/transform/integral.py", line 86, in integrate
    warn("The syntax 'integrate(ii, r0, c0, r1, c1)' is "
  File "/home/charris/Workspace/scikit-image/skimage/_shared/_warnings.py", line 16, in warn
    warnings.warn(message, stacklevel=stacklevel)
UserWarning: The syntax 'integrate(ii, r0, c0, r1, c1)' is deprecated, and will be phased out in release 0.14. The new syntax is 'integrate(ii, (r0, c0), (r1, c1))'.

scikit-imageには、 skimage/_shared/_warnings.py警告用に独自のコンテキストマネージャーがあることに注意してください。 suppress_warningsと競合している可能性があります。

好奇心から、デフォルトのUserWarningを使用する代わりに、 DeprecationWarningを明示的に指定することに違いがあるのではないかと思います。

だから私はエラーを見ません

$ nosetests-2.7 skimage/transform/tests/test_integral.py |& grep orig_show

一方、

$ nosetests-2.7 skimage/transform/tests/ |& grep orig_show

約25％の確率で表示されます。 これは、エラーの原因が他の場所にあり、失敗したテストがそれを明らかにしていることを示唆しています。

特に、 skimage/transform/tests/test_geometric.pyには警告コンテキストマネージャーexpected_warningsが含まれているため、疑わしいと思います。

OK、今私はtest_parallelデコレータ、 https：//github.com/scikit-image/scikit-image/blob/master/skimage/_shared/testing.pyを疑ってい

test_parallelインポートしている3つのファイルを削除すると、問題はなくなります。

編集：そして今、私は問題をまったく再現することができません。 うーん...多分また、マシン上で実行されている他のものに依存します。

うーん、 test_parallelは私が推測することかもしれませんが、コードを調べても、どの関数も明らかに警告コンテキストを使用していませんが、不可能ではないと思います。

test_hough_transform.py何かがイニシエーターのようです。 そのファイルを削除してもエラーはありません。

編集：おそらく、がtest_integral.pyモジュールの前にあるためですか？

問題はtest_hough_transform.pyでのこのテストにあるようです

@test_parallel()
def test_hough_circle():
    # Prepare picture
    img = np.zeros((120, 100), dtype=int)
    radius = 20
    x_0, y_0 = (99, 50)
    y, x = circle_perimeter(y_0, x_0, radius)
    img[x, y] = 1

    out1 = tf.hough_circle(img, radius)
    out2 = tf.hough_circle(img, [radius])
    assert_equal(out1, out2)
    out = tf.hough_circle(img, np.array([radius], dtype=np.intp))
    assert_equal(out, out1)
    x, y = np.where(out[0] == out[0].max())
    assert_equal(x[0], x_0)
    assert_equal(y[0], y_0)

特に、2行のいずれか

    assert_equal(out1, out2)

# or

    assert_equal(out, out1)

エラーを有効にします。

同様に、 @parallelデコレータを削除すると、エラーが修正されます。 したがって、結果として、ベクトルで呼び出されたassert_equalと組み合わせたスレッドが問題につながります。

理にかなっていますが、assert equal関数はそれを使用して".*NAT =="警告をフィルタリングします。 assert_equalが警告抑制を行うことはあまり明白ではないため、その関数から削除しようとする可能性があります（したがって、完全には行われません）スレッド化をサポート）。

チャックを追跡するのはいいことです！

それを削除しようとするのは良いことです。

スレッドセーフではない他のnumpy関数があるのだろうか？

確かではありませんが、私たちはテストスーツで警告のものだけを使用していると思います。 そして、 np.errstateはおそらくスレッドセーフですか？

この素晴らしい調査@charrisと@sebergに感謝します

うーん、少し面倒だと思います。 抑制を元の場所から削除すると、ダウンストリームの動作が変わる可能性があります。これはおそらく問題ありませんが（おそらくよりクリーンです）、バグ修正リリースに適しているかどうかはわかりません。 比較タイプのテストでミューテックスをロックすることもできます。これは原則として常に問題ない場合がありますが、どのように失敗するかは本当に考えられません。

assert_equal修正するだけで十分だと思います。いずれにせよ、NaT比較のために将来修正する必要があります。 NaTはint64に変換でき、値はmin_int64であることに注意してください。

ああ、確かに、私たちは実際にNaTを明示的にサポートすることができますが、現在は少し面倒です（NaTを具体的にチェックする機能がないため）が、難しいことではありません。 他の配列比較の周りにはこれらの別のものがありますが、私はそれがあまり使用されていないと思います（そして何のためにわからない）。

NaTロジックをアサートに追加することは、マスターにとってはかなりうまくいくようですが、バックポートに対してはうまくいくかどうかはわかりません。 suppress_warningsは新しいかもしれませんが、競合状態自体は前回のリリースですでに存在していたと思います。

まだisnat関数が必要であるか、 isnan datetime/timedeltaをサポートしている可能性があります。

はい、 isnat関数について同意します。 正確な場所には、 timedelta64とdatetime64 2つのタイプもあります。 NaT値もどこにも公開されていないことに注意してください。おそらく、 np.natも使用できます。 実際の定義はndarraytypes.hます。

@ charris 、Chuck、それについてどう思いますか？ np.isnat作成するか、 isnanで日時とtimedeltaを許可しますか？

うーん、すべてをisnanに入れるのは興味深い考えですが、現時点では、おそらく後で問題が発生する可能性があると思います。 @njsmith @juliantaylor考え？

@shoyerにも意見があるかもしれません。

isnat実装したばかりですが、リリースに関するすべてのタイミングについてはよくわかりません。 最小限のバージョンでこれを修正する必要がある場合は、Python isnatバージョンをテストスーツにプラグインすることをお勧めしますが、修正するのは少し難しいかもしれません（少なくとも他の人は以前よりも多くの警告を受け取りますが、1。テストスーツのものを使用し、2。実際に警告を注意深くテストします）。

失敗はそれほど深刻ではないと思いますが、修正してもらうといいでしょう。 isnatの（プライベート？）pythonバージョンは1.12で問題ありません。

suppress_warnings docstringは、スレッドセーフではないことにも言及する必要があります。

します ：）

休暇中にこの問題に飛びつき、徹底的なデバッグをしてくれた多くの人に感謝します

このソリューションを実装/テストするためにできることはありますか？ debianはこれを修正することを熱望しています:)

@sandrotosi 、残念ながらそれは少しトリッキーかもしれません、最も簡単な修正は単にskimageで並列テストのものを使用しないことかもしれませんが、それは目的をいくらか打ち負かします。 私のisnatのもののようなことをかなり簡単に行うことができます（isnatのプライベートPythonバージョンを使用）。 ただし、他の場所でテスト回帰が作成されない可能性があるかどうかはよくわかりません：/。

これらの2つのケースにミューテックスを追加することは、実際には問題を取り除くはずのもっともらしいハックであり、悪くなる可能性は低いようです（ assert_equal内部からassert_equalなどを呼び出さないため）。 私は実際にはそれをnumpymasterで使用しませんが、1.12の最小限のバグ修正として、それは本当のオプションかもしれません。 そして、それはskimageテスト自体に干渉しません。

@oleboleは、skimageでの並列テストを無効にしますか？

@sebergええ、ターゲットは1.12の最小限の修正を行い、最終的にはマスターでより完全で包括的な方法で対処することだと思います-少なくとも次のDebianリリースでこの問題が発生しなくても問題はありません

@ sandrotosigh -8427でロックアプローチを試しました。 私はその考えがナッツであるかどうかではありませんが、誰かがそれを試してみたいのなら....

suppress_warningsを単純に変更して未定義の動作をさせるが、マルチスレッド方式で使用した場合にクラッシュしないようにする方法はありますか？

（私にはいくつかのアイデアがありますが、それがどのように正確に機能するかについてはまだ考えています。）

確かに、属性を削除することはできませんが、後でテストでバグが発生する可能性があります...ほとんどのテストスーツは、警告のテストについては気難しいほどではないと思いますが...。

1.12.0rc2（https://github.com/numpy/numpy/pull/8427を含む）をdebianにアップロードし、skimageを3回再構築しました（テストスイートを完全に無効にしない、少し古いバージョンのdebianパッケージ）そして、それは常に成功裏に構築されました。

休暇中にこれに取り組んでくれてありがとう！

さて、最終的な1.12.0リリースの計画はありますか？ :)

最終リリースは1月15日を予定しています。

rc2で動作することを確認できます。 本当にありがとうございました！

マスターで修正されるまで、これを開いたままにしておきます。

うーん、マスターで修正されていません。 @ seberg ＃8421がこれを閉じるのは正しいですか？

＃8421で修正。