Numpy: RuntimeError：implement_array_functionメソッドにはすでにdocstringがあります

かなりのテストの後、それはuwsgi内で実行されることに関連していると確信しています。

これは漠然としたベルを鳴らします。 IIRC uwsgiは、 -OO実行するなど、ある種のdocstring操作を実行します。

これは、PythonコンソールにIPythonを使用するSpyderでも発生します。 「ユーザーモジュールリローダー」と呼ばれる手法があり、「PythonまたはIPythonコンソールでファイルを実行するときにインポートされたモジュールをPythonに強制的にリロードさせます」。 基本的にこれはdel sys.modules[modname]ます。

numpyをインポートするスクリプトを実行しようとすると、で終わるスタックトレースが表示されます。

[...]
numpyをnpとしてインポート

ファイル "C：\ Program Files \ Python35 \ lib \ site-packagesnumpy \ __ init__。py"、行142、
から 。 コアのインポート

ファイル "C：\ Program Files \ Python35 \ lib \ site-packagesnumpy \ core \ __ init __。py"、17行目
から 。 マルチアレイのインポート

ファイル「C：\ ProgramFiles \ Python35 \ lib \ site-packagesnumpy \ core \ multiarray.py」、14行目
から 。 インポートオーバーライド

ファイル「C：\ ProgramFiles \ Python35 \ lib \ site-packagesnumpy \ core \ overrides.py」、47行目
"" "）

RuntimeError：implement_array_functionメソッドにはすでにdocstringがあります

私にも起こります（Djangoサーバー）：

  File "/opt/project/consensx/graph/values_graph.py", line 2, in <module>
    import matplotlib.pyplot as plt
  File "/pyroot/lib/python3.7/site-packages/matplotlib/__init__.py", line 138, in <module>
    from . import cbook, rcsetup
  File "/pyroot/lib/python3.7/site-packages/matplotlib/cbook/__init__.py", line 31, in <module>
    import numpy as np
  File "/pyroot/lib/python3.7/site-packages/numpy/__init__.py", line 142, in <module>
    from . import core
  File "/pyroot/lib/python3.7/site-packages/numpy/core/__init__.py", line 17, in <module>
    from . import multiarray
  File "/pyroot/lib/python3.7/site-packages/numpy/core/multiarray.py", line 14, in <module>
    from . import overrides
  File "/pyroot/lib/python3.7/site-packages/numpy/core/overrides.py", line 47, in <module>
    """)
RuntimeError: implement_array_function method already has a docstring

Python 7.3.7
numpy：1.17.2

ここでの本当の問題は、NumPyがプロセスでの再初期化をサポートしていないことです。 これは2012年からgh-665に戻ります。これを解決するには、構造体で作成するすべてのグローバル状態を注意深くキャプチャし、モジュールのゲッターを介してそれにアクセスする必要があります。

ああ、グローバル。 それらはいつも楽しいです。

numpyをnumpy == 1.15.4にダウングレードすることで、うまくいきました。

numpyをnumpy == 1.15.4にダウングレードすることで、うまくいきました。

このバージョンのnumpy（1.15.4）は、魔女バージョンのパンダで動作しますか？
パンダの場合1.0.3 =
ValueError: numpy.ufunc size changed, may indicate binary incompatibility. Expected 216 from C header, got 192 from PyObject

他の質問、このバグはすぐに修正されると思いますか？

ありがとう。

他の質問、このバグはすぐに修正されると思いますか？

「このバグ」とは、numpyの削除と再インポートを許可することを意味する場合、答えは「ロードマップに含まれていません」です。 これはオープンソースであるため、誰でも修正に貢献できますが、かなり大規模な作業になります。

インポートの警告しかない場合は、無視してかまいません。 しかし、私はあなたがuwsgiを使用していると思います...

これがuwsgiによるものである場合、私はそれをサポートしないという答えしかありません。あなたはこれに非常に大きな努力を払わなければならないでしょう。 現時点では、 Pythonのすべてがこれをサポートしているわけではありませんが、いつか機能することを漠然と期待して取り組んでいます。 しかし、私たちにこの仕事をするように頼むことは、単にどこにも行きません。 確かに、あなたは状況を改善するために時間とお金を投資しようとすることができます、それは歓迎されます、しかしあなたの希望を上げないでください。

Pythonは彼らの最後に一緒に自分の事を取得した後、（これは、しばらく時間がかかることがあり、彼らは何年
現時点では、私の知る限り、wsgiが行うことと基本的に互換性のないパブリックAPIがあり（サブインタープリターを使用）、おそらく必要な最適化されたキャッシュがいくつかありますが、私の知る限り、Python

事実、wsgiがデフォルトで使用するサブインタープリターは、妥当なサイズのC拡張システムではサポートされていません。 そして、これは予見可能な将来には起こりません。 そして、誰かがこれをNumPyロードマップの重要なことだと考えたり期待したりすると、私の意見では、Python開発者は彼らのシグナルを間違えました（そして私はそう言った、そしてそれはそこで認められているようでした）。 サブインタープリターはC拡張機能の大部分でひどく失敗すると想定する必要があること、中期（今後数年）に状況が変化することを誰も期待してはならないこと、そして基本的にこの機能は実験的なものであることを全員に伝える必要があるためです。 C拡張機能のサポートになります。

はい、多くのPythonコア開発者は物事を機能させる方向に進んでいますが、NumPyなどのプロジェクトの観点からは、サブインタープリター（wsgiのデフォルト）のサポートは、Python2からPython3への移行よりも簡単ではありません。潜在的なユーザーであり、現在、すべてを適切にサポートするテクノロジーすらありません。

だから、この暴言の後...誰かがNumPyを（サブインタープリターでより良く）機能させるために努力を費やしたいのであれば、これを閉じます。それは高貴な努力です。 そして、私は間違っていることが証明されてうれしいです...しかし、私はサブインタープリター（wsgi）が実験的で機能的であると見なされなければならないという点に立ってい

ええと、私たちはサブインタープリターを気にしないことに完全に同意します（とにかく）が、これはより単純な問題です-1.15.4で機能し、Django、Spyderなどのレポートにはuwsgi含まれていません。 __array_function__のdocstring添付ファイルを簡単に変更します。

本当はそれらを逃した。 そこにもあるのだろうか...その文脈ではかなり安全なはずです。 うまくいけば、メモリリークのみが発生するという意味で。 （少なくとも、CPythonがC-extensionモジュールがそれを安全に実装していると言うためのより多くの機械を取得するまで、SpyderがC-extensionモジュールをスキップするべきではないかどうかまだ少し疑問です...そしてそれでも、ほとんどのC-extensionモジュールはリロードしますおそらくほとんど何もしません）。

それでも、ほとんどのC拡張モジュールでは、リロードはおそらくほとんど何もしません）。

それがポイントだとは思いません。 Pythonパッケージの一部としてコンパイルされた拡張機能がぶら下がっている場合は、試してみる前に理解するよりも、 reload(any_module)と言う方がはるかに簡単です。

Djangoが正確に何をするかはわかりませんが、おそらく似ています。

私はあなたをあまり苛立たせたくありませんでした。

私はFlaskとNumpyを使用するWebサービスを持っていますが、私だけではないと思います。
Flaskに含まれている開発サーバー（確かにWerkzeug）にエラーはありません。

実際、本番環境では、Python3用のapache2 WSGIモジュールを使用しています。これにより、負荷を保持できます（複数のスレッド）

私は開いています、何を使うべきか教えてください：

• Gunicornまたは他のサーバー？ しかし、それもWSGIです
• mod_wsgi-express ？
• または、mod_wsgiでどのオプションを変更する必要がありますか？ 、modwsgiのドキュメントのサブインタープリターの段落でそれを読みました：WSGIApplicationGroup％{GLOBAL}

どうもありがとうございます。

サブインタープリターの段落にあるものはすべて、NumPyに関して適切なアドバイスである必要があります。 Webサービスで何が機能するかについてアドバイスすることはできませんが、このスレッドの他の誰かがアドバイスできるかもしれません。

状況を少し良くすることは良いかもしれない（そしていくつかを助けるかもしれない）が、予見可能な将来の深い問題を解決しないことを明確にしたかっただけです。 いずれにせよ、私たちはこの失敗を取り除こうとするかもしれないと思いますが、代わりにこれがデバッグの困難な問題につながる可能性があるという大きな警告を出します。

たぶんそれは前に言及されなかったので誰かを助けるでしょう：
私はuwsgi （Nginxを使用）を使用しており、 " single-interpreter = true " ini config（または--single-interpreter switch）がこの問題を解決しました。

ここで私はこのフラグの説明を見つけました：

デフォルトでは、uWSGIは、Pythonが最初に初期化されたときに作成されたメインのPythonインタープリターではなく、プロセスのサブインタープリター内でPythonコードを実行します。 これは、複数の個別のPython Webアプリケーションを1つのプロセス内で実行できるようにするために行われますが、相互に干渉しないように十分に分離する必要があります。 ただし、スレッドを有効にしてサブインタープリターを使用すると、古いバージョンのuWSGIが失敗する可能性があります。 したがって、このオプションを使用して、プロセスごとに1つのWebアプリケーションに制限するのが最も安全です。 uWSGIを使用して各プロセスで単一のWebアプリケーションを実行することは通常の使用例であるため、この制限が問題になる可能性はほとんどありません。

したがって、回避策として、この構成でuwsgiに切り替えるか、ご使用の環境に類似したものを見つけてみてください。

修正/回避策を実際にマージするまで再開します-間もなく開始されるはずです。

昨日も同じエラーが発生しましたが、何が起こったのかわかりませんでした。 完成のために、ここで原因を説明します。Numpy内で何かを上書きしていたlogger.pyという名前のロガーモジュールがありました。 モジュール名を変更しました。エラーはありません。 たぶん、他の誰かがこのコメントに出くわし、似たようなことが彼らに起こっていることを理解するでしょう。

1.19の修正をプッシュしました。 または、エラーがまだ問題を引き起こす可能性のある何かが起こっていることを示しているので、むしろ回避策かもしれません。

1.19の回避策を持つ@sebergは、これを閉じる必要がありますか？