Numpy: RuntimeError: Methode implement_array_function hat bereits einen Docstring

Nach einigen Tests bin ich mir ziemlich sicher, dass dies mit der Ausführung innerhalb von uwsgi .

Dies läutet eine vage Glocke. IIRC uwsgi führt eine Art Docstring-Manipulation durch, wie zum Beispiel das Ausführen mit -OO .

Dies geschieht auch in Spyder, das IPython für seine Python-Konsole verwendet. Sie haben eine Technik namens "User Module Reloader", die "Python zwingt, Module neu zu laden, die beim Ausführen einer Datei in einer Python- oder IPython-Konsole importiert wurden". Im Grunde ist dies del sys.modules[modname] .

Wenn ich versuche, ein Skript auszuführen, das numpy importiert, erhalte ich einen Stack-Trace mit der Endung

[…]
numpy als np importieren

Datei "C:\Programme\Python35\lib\site-packagesnumpy\__init__.py", Zeile 142, in
von . Kern importieren

Datei "C:\Programme\Python35\lib\site-packagesnumpy\core\__init__.py", Zeile 17, in
von . Multiarray importieren

Datei "C:\Programme\Python35\lib\site-packagesnumpy\core\multiarray.py", Zeile 14, in
von . Überschreibungen importieren

Datei "C:\Programme\Python35\lib\site-packagesnumpy\core\overrides.py", Zeile 47, in
""")

RuntimeError: Methode implement_array_function hat bereits einen Docstring

Passiert mir auch (Django-Server):

  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

Das eigentliche Problem dabei ist, dass NumPy die Neuinitialisierung während des Prozesses nicht unterstützt. Dies geht zurück auf gh-665 aus dem Jahr 2012. Um dies zu lösen, müssen wir den gesamten globalen Zustand, den wir in einer Struktur erstellen, sorgfältig erfassen und über einen Getter auf dem Modul darauf zugreifen.

Oh, Globale. Die machen immer Spaß.

Das Herabstufen von numpy auf numpy==1.15.4 hat mir geholfen.

Das Herabstufen von numpy auf numpy==1.15.4 hat mir geholfen.

Diese Version von numpy (1.15.4) funktioniert mit der Hexenversion von Pandas ?
Denn mit Pandas 1.0.3 =
ValueError: numpy.ufunc size changed, may indicate binary incompatibility. Expected 216 from C header, got 192 from PyObject

Andere Frage, glauben Sie, dass dieser Fehler bald behoben wird?

Vielen Dank.

Andere Frage, glauben Sie, dass dieser Fehler bald behoben wird?

Wenn Sie mit "dieser Fehler" meinen, dass Numpy gelöscht und neu importiert werden darf, lautet die Antwort "Es steht nicht auf unserer Roadmap". Dies ist Open Source, sodass jeder dazu beitragen kann, es zu beheben, aber es wird ein ziemlich großes Unterfangen sein.

Wenn Sie nur eine Importwarnung haben, können Sie diese ignorieren. Aber ich denke du verwendest uwsgi...

Wenn dies auf uwsgi zurückzuführen ist, dann habe ich nur die Antwort, dass wir es nicht unterstützen werden und Sie dafür einen sehr großen Aufwand betreiben müssten. Zurzeit unterstützt noch nicht einmal ganz Python dies, sie arbeiten daran mit der vagen Hoffnung, dass es eines Tages funktionieren wird. Aber uns zu bitten, dass dies funktioniert, wird einfach nirgendwo hingehen. Sicher, Sie können versuchen, Zeit und Geld in die Verbesserung der Situation zu investieren, das ist willkommen, aber machen Sie sich keine Hoffnungen.

Nachdem Python sich am Ende zusammengetan hat (das kann eine Weile dauern, sie arbeiten viele Jahre daran) und es eine relativ große Benutzerbasis gibt, könnte es ein Interesse daran geben.
Zu diesem Zeitpunkt haben wir eine öffentliche API, die meines Wissens im Wesentlichen nicht mit dem bietet meines Wissens

Tatsache ist, dass Sub-Interpreter, die wsgi standardmäßig verwendet, von einer vernünftigen Größe des C-Erweiterungssystems einfach nicht unterstützt werden. Und das wird auf absehbare Zeit nicht passieren. Und wenn irgendjemand dies als eine wichtige Sache der NumPy-Roadmap denkt oder erwartet, dann haben meiner Meinung nach Python-Entwickler ihre Signale falsch verstanden (und ich habe es gesagt, und es schien dort anerkannt zu werden). Denn sie sollten jedem sagen, dass man davon ausgehen muss, dass Sub-Interpreter bei den allermeisten C-Erweiterungen fürchterlich versagen, dass niemand damit rechnen sollte, dass sich die Situation mittelfristig (in den nächsten Jahren) ändert, und dass das Feature im Grunde genommen experimentell ist, wenn es geht um C-Erweiterungsunterstützung.

Ja, viele Python-Kernentwickler bewegen sich glücklich in die Richtung, dass die Dinge funktionieren, aber aus der Perspektive eines Projekts wie NumPy ist die Unterstützung von Subinterpretern (wsgi-Standardeinstellungen) nicht einfacher als der Übergang von Python 2 zu Python 3 mit einem Bruchteil von potentielle Nutzer und derzeit noch nicht einmal die Technik, um alles richtig zu unterstützen!

Also, nach diesem Gerede... Ich schließe das hier, falls jemand die Mühe aufwenden möchte, NumPy zum Funktionieren zu bringen (besser mit Sub-Interpretern), das ist eine edle Anstrengung. Und ich bin froh, dass mir das Gegenteil bewiesen wird... Aber ich bleibe bei dem Punkt, dass Sub-Interpreter (wsgi) als experimentell und Feature betrachtet werden müssen . Dh, wenn Sie Sub-Interpreter verwenden, ist es eher so, als würden Sie eine Rand-Python-Implementierung verwenden (wie ein frühes PyPy). Und es dauerte Jahre, bis jemand, der PyPy verwendet, erwartete, NumPy innerhalb von PyPy auszuführen (und PyPy hat die ganze Arbeit geleistet, um dies zu ermöglichen) ...

Äh, ich stimme voll und ganz zu, dass wir uns nicht um Subinterpreter kümmern (noch sowieso), aber das ist ein einfacheres Problem - es funktionierte in 1.15.4 und die Django-, Spyder- usw.-Berichte beinhalten nicht uwsgi . Ich werde kurz versuchen, den docstring-Anhang in __array_function__ zu ändern.

True hat die verpasst. Obwohl ich mich da auch frage... sollte es in diesem Zusammenhang ziemlich sicher sein. In dem Sinne, dass es hoffentlich nur Speicherverluste gibt. (Ich frage mich immer noch, ob Spyder nicht einfach C-Erweiterungsmodule überspringen sollte, zumindest bis CPython mehr Maschinen bekommt, die sagen, dass ein C-Erweiterungsmodul es sicher implementiert ... Und selbst dann, für die meisten C-Erweiterungsmodule nachladen tut wahrscheinlich fast nichts).

Und selbst dann bewirkt das Nachladen bei den meisten C-Erweiterungsmodulen wahrscheinlich fast nichts).

Ich glaube nicht, dass das der Punkt ist. Es ist viel einfacher, reload(any_module) zu sagen, als vorher herauszufinden, ob eine kompilierte Erweiterung als Teil eines Python-Pakets herumhängt.

Ich bin mir nicht sicher, was Django genau macht, aber es ist wahrscheinlich ähnlich.

Ich wollte dich nicht zu sehr ärgern.

Ich habe einen Webdienst, der Flask und Numpy verwendet, ich denke, ich bin nicht der einzige.
Ich habe keine Fehler mit dem in Flask enthaltenen Entwicklungsserver (auf jeden Fall Werkzeug).

Und tatsächlich verwende ich in der Produktion das Apache2-WSGI-Modul für Python3, mit dem ich die Last halten kann (mehrere Threads).

Ich bin offen, sag mir, was ich verwenden soll:

• Gunicorn oder anderer Server? aber das ist auch WSGI
• mod_wsgi-express ?
• oder welche Option sollte ich in mod_wsgi ändern?, das habe ich in den Abschnitts - Unterinterpretern in der Dokumentation von modwsgi gelesen: WSGIApplicationGroup %{GLOBAL}

Vielen Dank.

Alles im Unterinterpreter-Absatz sollte ein fundierter Rat in Bezug auf NumPy sein. Ich kann keinen Rat geben, was für Webdienste funktionieren könnte, aber vielleicht kann jemand anderes in diesem Thread.

Ich wollte nur klarstellen, dass eine geringfügige Verbesserung der Situation gut sein kann (und einigen helfen), aber die tiefliegenden Probleme in absehbarer Zeit nicht lösen wird. Auf jeden Fall können wir versuchen, diesen Fehler zu beheben, aber stattdessen eine große Warnung ausgeben, dass dies zu schwer zu debuggenden Problemen führen kann.

Vielleicht hilft es jemandem, da es vorher nicht erwähnt wurde:
Ich verwende uwsgi (mit Nginx) und die INI-Konfiguration " Single-Interpreter = true " (oder --single-interpreter- Schalter) hat dieses Problem für mich gelöst .

Hier habe ich die Erklärung zu dieser Flagge gefunden:

Standardmäßig führt uWSGI Python-Code in einem Unterinterpreter des Prozesses aus und nicht im Python-Hauptinterpreter, der bei der ersten Initialisierung von Python erstellt wurde. Dies geschieht, damit mehrere separate Python-Webanwendungen innerhalb eines Prozesses ausgeführt werden können, jedoch ausreichend voneinander getrennt sind, um sich nicht gegenseitig zu stören. Ältere Versionen von uWSGI können jedoch fehlschlagen, wenn Subinterpreter mit aktiviertem Threading verwendet werden. Daher ist es am sichersten, diese Option zu nutzen und sich auf eine einzige Webanwendung pro Prozess zu beschränken. Das Ausführen einer einzelnen Webanwendung in jedem Prozess mit uWSGI ist der normale Anwendungsfall, daher ist es unwahrscheinlich, dass diese Einschränkung ein Problem darstellt.

Als Workaround können Sie mit dieser Konfiguration zu uwsgi wechseln oder versuchen, etwas Ähnliches für Ihre Umgebung zu finden.

Wird wieder geöffnet, bis wir tatsächlich einen Fix/Workaround zusammenführen - sollte bald sein.

Mir ist gestern der gleiche Fehler passiert und ich konnte einfach nicht herausfinden, was passiert war. Nur der Vollständigkeit halber habe ich hier meine Ursache: Ich hatte ein Logger-Modul namens logger.py, das etwas in Numpy überschrieb. Modulname geändert, keine Fehler. Vielleicht wird jemand anderes auf diesen Kommentar stoßen und herausfinden, dass ihm etwas Ähnliches passiert.

Wir haben einen Fix für 1.19 verschoben. Oder vielleicht eher eine Problemumgehung, da der Fehler immer noch anzeigt, dass etwas vor sich geht, das Probleme verursachen könnte.

@seberg mit dem Workaround in 1.19 sollen wir das schließen?