Numpy: RuntimeError : la méthode implement_array_function a déjà une docstring

Après pas mal de tests, je suis presque sûr que cela est lié à l'exécution dans uwsgi .

Cela sonne une vague cloche. IIRC uwsgi effectue une sorte de manipulation de docstring, comme s'exécuter avec -OO .

Cela se produit également dans Spyder, qui utilise IPython pour sa console Python. Ils ont une technique appelée « user module reloader », qui « force Python à recharger les modules qui ont été importés lors de l'exécution d'un fichier dans une console Python ou IPython ». Fondamentalement, cela fait del sys.modules[modname] .

Lorsque j'essaie d'exécuter un script qui importe numpy, j'obtiens une trace de pile se terminant par

[...]
importer numpy en tant que np

Fichier "C:\Program Files\Python35\lib\site-packagesnumpy\__init__.py", ligne 142, dans
de . importer le noyau

Fichier "C:\Program Files\Python35\lib\site-packagesnumpy\core\__init__.py", ligne 17, dans
de . importer multiarray

Fichier "C:\Program Files\Python35\lib\site-packagesnumpy\core\multiarray.py", ligne 14, dans
de . importer des remplacements

Fichier "C:\Program Files\Python35\lib\site-packagesnumpy\core\overrides.py", ligne 47, dans
""")

RuntimeError : la méthode implement_array_function a déjà une docstring

Ca m'arrive aussi (serveur 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

Le vrai problème ici est que NumPy ne prend pas en charge la réinitialisation dans le processus. Cela remonte à gh-665 à partir de 2012. Pour résoudre ce problème, il faudrait capturer soigneusement tout l'état global que nous créons dans une structure et y accéder via un getter sur le module.

Oh, les mondiaux. Ceux-là sont toujours amusants.

La rétrogradation de numpy à numpy = = 1.15.4 a fait l'affaire pour moi.

La rétrogradation de numpy à numpy = = 1.15.4 a fait l'affaire pour moi.

Cette version de numpy (1.15.4) fonctionne avec quelle version de pandas ?
Parce qu'avec les pandas 1.0.3 =
ValueError: numpy.ufunc size changed, may indicate binary incompatibility. Expected 216 from C header, got 192 from PyObject

Autre question, pensez-vous que ce bug sera bientôt corrigé ?

Merci beaucoup.

Autre question, pensez-vous que ce bug sera bientôt corrigé ?

Si par "ce bug" vous entendez autoriser numpy à être supprimé et réimporté, alors la réponse est "Ce n'est pas sur notre feuille de route". C'est open source donc n'importe qui peut contribuer à le réparer, mais ce sera une entreprise assez importante.

Si tout ce que vous avez est un avertissement d'importation, vous pouvez l'ignorer. Mais je suppose que vous utilisez uwsgi...

Si cela est dû à uwsgi, alors je n'ai que la réponse que nous ne le soutiendrons pas et que vous devrez faire un effort très important pour cela. À l'heure actuelle, même tout Python ne prend pas en charge cela, ils y travaillent avec un vague espoir qu'un jour cela fonctionnera. Mais nous demander de faire ce travail n'ira tout simplement nulle part. Bien sûr, vous pouvez essayer d'investir du temps et de l'argent pour améliorer la situation, c'est bienvenu, mais n'ayez pas espoir.

Une fois que Python se sera mis d'accord (cela peut prendre un certain temps, ils y travaillent depuis de nombreuses années) et qu'il existe une base d'utilisateurs assez importante, il pourrait y avoir un certain intérêt.
En ce moment, nous avons une API publique qui à ma connaissance est fondamentalement incompatible avec ce que fait wsgi (utiliser des sous-interprètes), et nous avons probablement des caches optimisés que nous voulons probablement et Python à ma connaissance ne fournit pas encore de mécanisme pour faire rapidement dans ce cadre .

Le fait est que les sous-interprètes que wsgi utilise par défaut ne sont tout simplement pas pris en charge par une taille raisonnable du système d'extension C. Et cela ne se produira pas dans un avenir prévisible. Et si quelqu'un pense ou s'attend à ce que cela soit une chose importante de la feuille de route NumPy, alors à mon avis, les développeurs Python se sont trompés dans leurs signaux (et je l'ai dit, et cela semblait être reconnu ici). Parce qu'ils devraient dire à tout le monde que les sous-interprètes doivent être supposés échouer horriblement avec la grande majorité des extensions C, que personne ne devrait s'attendre à ce que la situation change à moyen terme (dans les prochaines années), et fondamentalement que la fonctionnalité est expérimentale quand il s'agit de la prise en charge de l'extension C.

Oui, de nombreux développeurs principaux de Python s'orientent joyeusement dans le sens de faire fonctionner les choses, mais du point de vue d'un projet tel que NumPy, la prise en charge des sous-interprètes (valeurs par défaut de wsgi) n'est pas plus facile que la transition Python 2 à Python 3 avec une fraction de utilisateurs potentiels et actuellement même pas la technologie pour tout prendre en charge correctement !

Donc, après cette diatribe... Je vais fermer ceci, si quelqu'un veut faire l'effort de faire fonctionner NumPy (mieux avec des sous-interprètes), c'est un noble effort. Et je suis heureux d'avoir tort... Mais je suis d'accord avec le fait que les sous-interprètes (wsgi) doivent être considérés comme une fonctionnalité expérimentale . C'est-à-dire que si vous utilisez des sous-interprètes, cela ressemble plus à l'utilisation d'une implémentation Python marginale (comme un PyPy précoce). Et il a fallu des années avant que quiconque utilisant PyPy s'attende à exécuter NumPy dans PyPy (et PyPy a fait tout le travail pour y arriver)...

Eh, je suis tout à fait d'accord pour dire que nous ne nous soucions pas des sous-interprètes (en tout cas), mais c'est un problème plus simple - cela fonctionnait en 1.15.4 et les rapports Django, Spyder, etc. n'impliquent pas uwsgi . Je vais essayer de changer rapidement la pièce jointe docstring dans __array_function__ .

Vrai raté ceux-là. Bien que je me demande aussi là-bas... cela devrait être assez sûr dans ce contexte. Dans le sens où, espérons-le, il ne fuit que de la mémoire. (Je me demande encore un peu si Spyder ne devrait pas simplement ignorer les modules d'extension C, au moins jusqu'à ce que CPython obtienne plus de machines pour dire qu'un module d'extension C l'implémente en toute sécurité... Et même alors, pour la plupart des modules d'extension C, le rechargement ne fait probablement presque rien).

Et même alors, pour la plupart des modules d'extension C, le rechargement ne fait probablement presque rien).

Je ne pense pas que ce soit le but. Il est beaucoup plus facile de dire reload(any_module) que de comprendre avant d'essayer s'il existe une extension compilée qui traîne dans le cadre d'un package Python.

Je ne sais pas exactement ce que fait Django, mais c'est probablement similaire.

Je ne voulais pas trop t'embêter.

J'ai un service Web qui utilise Flask et Numpy, je suppose que je ne suis pas le seul.
Je n'ai aucune erreur avec le serveur de développement (certainement Werkzeug) inclus dans Flask.

Et effectivement, en production, j'utilise le module apache2 WSGI pour Python3, qui me permet de tenir la charge (plusieurs threads)

Je suis ouvert, dis moi quoi utiliser :

• Gunicorn ou autre serveur ? mais c'est aussi WSGI
• mod_wsgi-express ?
• ou quelle option dois-je changer dans mod_wsgi?, j'ai lu cela dans les sous-interprètes de paragraphe dans la documentation de modwsgi : WSGIApplicationGroup %{GLOBAL}

Merci beaucoup.

Tout ce qui se trouve dans le paragraphe du sous-interprète devrait être un bon conseil en ce qui concerne NumPy. Je ne peux pas donner de conseils sur ce qui peut fonctionner pour les services Web, mais peut-être que quelqu'un d'autre dans ce fil le peut.

Je voulais juste être clair sur le fait qu'améliorer légèrement la situation peut être une bonne chose (et en aider certains), mais ne résoudra pas les problèmes profonds dans un avenir prévisible. Dans tous les cas, je suppose que nous pouvons essayer de supprimer cet échec, mais à la place, nous avertissons fortement que cela peut entraîner des problèmes difficiles à déboguer.

Peut-être que cela aidera quelqu'un car cela n'a pas été mentionné auparavant :
J'utilise uwsgi (avec Nginx) et la configuration ini " single-interpreter = true " (ou --single-interpreter switch) a résolu ce problème pour moi .

Ici, j'ai trouvé l'explication de ce drapeau:

Par défaut, uWSGI exécutera le code Python dans un sous-interpréteur du processus plutôt que dans l'interpréteur Python principal créé lors de la première initialisation de Python. Ceci est fait pour permettre à plusieurs applications Web Python distinctes d'être exécutées au sein d'un seul processus, mais suffisamment séparées pour ne pas interférer les unes avec les autres. Les anciennes versions d'uWSGI peuvent toutefois échouer lors de l'utilisation de sous-interprètes avec le threading activé. Il est donc plus sûr d'utiliser cette option et de se limiter à une seule application web par processus. L'exécution d'une seule application Web dans chaque processus avec uWSGI est le cas d'utilisation normal, il serait donc peu probable que cette restriction pose un problème.

Ainsi, comme solution de contournement, vous pouvez passer à uwsgi avec cette configuration ou essayer de trouver quelque chose de similaire pour votre environnement.

Rouvrira jusqu'à ce que nous fusionnions réellement un correctif / une solution de contournement - cela devrait être bientôt.

J'ai eu cette même erreur hier, et je ne pouvais tout simplement pas savoir ce qui s'était passé. Juste pour terminer, je vais avoir ma cause ici: j'avais un module d'enregistrement, nommé logger.py, qui écrasait quelque chose dans Numpy. Modification du nom du module, aucune erreur. Peut-être que quelqu'un d'autre tombera sur ce commentaire et comprendra que quelque chose de similaire lui arrive.

Nous avons poussé un correctif pour la 1.19. Ou peut-être plutôt une solution de contournement, car l'erreur indique toujours que quelque chose se passe qui pourrait créer des problèmes.

@seberg avec la solution de contournement dans 1.19 devrions-nous fermer cela?