Numpy: RuntimeError: el método implement_array_function ya tiene una cadena de documentos

Después de algunas pruebas, estoy bastante seguro de que está relacionado con la ejecución dentro de uwsgi .

Esto suena a una campana vaga. IIRC uwsgi realiza algún tipo de manipulación de la cadena de documentos, como ejecutar con -OO .

Esto también sucede en Spyder, que usa IPython para su consola Python. Tienen una técnica llamada "recargador de módulos de usuario", que "obliga a Python a recargar los módulos que fueron importados al ejecutar un archivo en una consola de Python o IPython". Básicamente, esto hace del sys.modules[modname] .

Cuando intento ejecutar un script que importa numpy, obtengo un seguimiento de pila que termina en

[...]
importar numpy como np

Archivo "C: \ Archivos de programa \ Python35 \ lib \ site-packagesnumpy \ __ init__.py", línea 142, en
de . núcleo de importación

Archivo "C: \ Archivos de programa \ Python35 \ lib \ site-packagesnumpy \ core \ __ init__.py", línea 17, en
de . importar multiarray

Archivo "C: \ Archivos de programa \ Python35 \ lib \ site-packagesnumpy \ core \ multiarray.py", línea 14, en
de . importar anulaciones

Archivo "C: \ Archivos de programa \ Python35 \ lib \ site-packagesnumpy \ core \ overrides.py", línea 47, en
"" ")

RuntimeError: el método implement_array_function ya tiene una cadena de documentos

A mí también me pasa (servidor 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

El problema real aquí es que NumPy no admite la reinicialización en el proceso. Esto se remonta a gh-665 de 2012. Resolver esto requeriría capturar cuidadosamente todo el estado global que creamos en una estructura y acceder a él a través de un getter en el módulo.

Oh, globales. Siempre son divertidos.

La degradación de numpy a numpy == 1.15.4 funcionó para mí.

La degradación de numpy a numpy == 1.15.4 funcionó para mí.

¿Esta versión de numpy (1.15.4) funciona con la versión bruja de pandas?
Porque con pandas 1.0.3 =
ValueError: numpy.ufunc size changed, may indicate binary incompatibility. Expected 216 from C header, got 192 from PyObject

Otra pregunta, ¿cree que este error se solucionará pronto?

Muchas gracias.

Otra pregunta, ¿cree que este error se solucionará pronto?

Si por "este error" te refieres a permitir que numpy sea eliminado y reimportado, entonces la respuesta es "No está en nuestra hoja de ruta". Esto es de código abierto, por lo que cualquiera puede contribuir a solucionarlo, pero será una empresa bastante grande.

Si todo lo que tiene es una advertencia de importación, puede ignorarla. Pero supongo que estás usando uwsgi ...

Si esto se debe a uwsgi, entonces solo tengo la respuesta de que no lo apoyaremos y tendrías que hacer un esfuerzo muy significativo en esto. En este momento, ni siquiera todo Python admite esto, están trabajando en ello con la vaga esperanza de que algún día funcione. Pero pedirnos que hagamos que esto funcione simplemente no irá a ninguna parte. Claro, puedes intentar invertir tiempo y dinero para mejorar la situación, eso es bienvenido, pero no te hagas ilusiones.

Después de que Python arregle lo suyo (esto puede llevar un tiempo, están trabajando en esto durante muchos años) y hay una base de usuarios razonablemente grande, es posible que haya cierto interés en él.
En este momento, tenemos una API pública que, según mi conocimiento, es fundamentalmente incompatible con lo que hace wsgi (usar sub-intérpretes), y probablemente tengamos algunos cachés optimizados que probablemente queramos y Python, que yo sepa , aún no proporciona ningún mecanismo para hacer rápidamente en este entorno .

El hecho es que los sub-intérpretes que usa wsgi por defecto simplemente no son compatibles con un tamaño razonable del sistema de extensión C. Y esto no sucederá en el futuro previsible. Y si alguien piensa o espera que esto sea algo importante en la hoja de ruta de NumPy, entonces, en mi opinión, los desarrolladores de Python se equivocaron en sus señales (y lo he dicho, y parece que se reconoce allí). Porque deberían decirles a todos que se debe asumir que los sub-intérpretes fallan horriblemente con la gran mayoría de las extensiones C, que nadie debería esperar que la situación cambie a medio plazo (los próximos años), y básicamente que la función es experimental cuando se trata del soporte de extensión C.

Sí, muchos desarrolladores centrales de Python se están moviendo felizmente en la dirección de hacer que las cosas funcionen, pero desde la perspectiva de un proyecto como NumPy, admitir sub-intérpretes (valores predeterminados de wsgi) no es más fácil que la transición de Python 2 a Python 3 con una fracción de usuarios potenciales y actualmente ni siquiera la tecnología para soportar adecuadamente todo!

Entonces, después de esta perorata ... cerraré esto, si alguien quiere gastar el esfuerzo en hacer que NumPy funcione (mejor con sub-intérpretes) ese es un esfuerzo noble. Y estoy feliz de que se demuestre que estoy equivocado ... Pero estoy con el punto de que los sub-intérpretes (wsgi) deben considerarse una característica y experimental . Es decir, si usa sub-intérpretes, es más como usar alguna implementación de Python marginal (como un PyPy temprano). Y pasaron años antes de que cualquiera que usara PyPy esperara ejecutar NumPy dentro de PyPy (y PyPy hizo todo el trabajo para que esto sucediera) ...

Eh, estoy totalmente de acuerdo en que no nos importan los subinterpretes (todavía de todos modos), pero este es un problema más simple: funcionó en 1.15.4 y los informes de Django, Spyder, etc.no involucran uwsgi . Intentaré cambiar el archivo adjunto de la cadena de documentos en __array_function__ .

True los extrañaba. Aunque me pregunto también allí ... debería ser bastante seguro en ese contexto. En el sentido de que, con suerte, solo se filtra la memoria. (Todavía me pregunto un poco si Spyder no debería simplemente omitir los módulos de extensión C, al menos hasta que CPython obtenga más maquinaria para decir que un módulo de extensión C lo implementa de manera segura ... E incluso entonces, para la mayoría de los módulos de extensión C que se recargan probablemente no hace casi nada).

E incluso entonces, para la mayoría de los módulos de extensión C, la recarga probablemente no hace casi nada).

No creo que ese sea el punto. Es mucho más fácil decir reload(any_module) que darse cuenta antes de intentarlo si hay alguna extensión compilada dando vueltas como parte de un paquete de Python.

No estoy seguro de qué hace Django exactamente, pero probablemente sea similar.

No quería molestarte demasiado.

Tengo un servicio web que usa Flask y Numpy, supongo que no soy el único.
No tengo errores con el servidor de desarrollo (ciertamente Werkzeug) incluido en Flask.

Y de hecho, en producción, utilizo el módulo apache2 WSGI para Python3, que me permite mantener la carga (varios subprocesos)

Estoy abierto, dime qué usar:

• Gunicorn u otro servidor? pero eso es WSGI también
• mod_wsgi-express ?
• ¿o qué opción debo cambiar en mod_wsgi ?, leí eso en sub-intérpretes de párrafo en la documentación de modwsgi: WSGIApplicationGroup% {GLOBAL}

Muchísimas gracias.

Cualquier cosa en el párrafo del sub-intérprete debe ser un buen consejo con respecto a NumPy. No puedo dar ningún consejo sobre lo que puede funcionar para los servicios web, pero tal vez alguien más en este hilo pueda hacerlo.

Solo quería dejar en claro que mejorar un poco la situación puede ser bueno (y ayudar un poco), pero no resolverá los problemas más profundos en el futuro previsible. En cualquier caso, supongo que podemos intentar eliminar esta falla, pero en su lugar damos una gran advertencia de que esto puede conducir a problemas difíciles de depurar.

Tal vez ayude a alguien como no se mencionó antes:
Estoy usando uwsgi (con Nginx) y la configuración de ini " single-interpreter = true " (o --single-interpreter switch) me resolvió este problema .

Aquí encontré la explicación de esta bandera:

De forma predeterminada, uWSGI ejecutará el código Python dentro de un sub-intérprete del proceso en lugar del intérprete principal de Python creado cuando Python se inicializa por primera vez. Esto se hace para permitir que se ejecuten múltiples aplicaciones web Python separadas dentro de un proceso, pero que estén lo suficientemente separadas como para no interferir entre sí. Sin embargo, las versiones anteriores de uWSGI pueden fallar cuando se utilizan sub intérpretes con subprocesos habilitados. Por lo tanto, es más seguro utilizar esta opción y restringirse a una sola aplicación web por proceso. La ejecución de una sola aplicación web en cada proceso con uWSGI es el caso de uso normal, por lo que es poco probable que esta restricción sea un problema.

Entonces, como solución alternativa, puede cambiar a uwsgi con esta configuración o intentar encontrar algo similar para su entorno.

Se volverá a abrir hasta que combinemos una solución / solución temporal; debería ser pronto.

Ayer se me ocurrió el mismo error y no pude averiguar qué había sucedido. Solo para completar, tendré mi causa aquí: tenía un módulo de registro, llamado logger.py, que estaba sobrescribiendo algo dentro de Numpy. Se cambió el nombre del módulo, sin errores. Tal vez alguien más se encuentre con este comentario y se dé cuenta de que les está sucediendo algo similar.

Hemos presionado una solución para 1,19. O tal vez más bien una solución alternativa, ya que el error aún indica que algo está sucediendo que podría crear problemas.

@seberg con la solución en 1.19 ¿deberíamos cerrar esto?