Numpy: RuntimeError: o método implement_array_function já tem uma docstring

Depois de alguns testes, tenho certeza de que está relacionado a ser executado dentro de uwsgi .

Isso soa um sino vago. IIRC uwsgi faz algum tipo de manipulação de docstring, como correr com -OO .

Isso também acontece no Spyder, que usa IPython para seu console Python. Eles têm uma técnica chamada "recarregador de módulo de usuário", que "força o Python a recarregar módulos que foram importados ao executar um arquivo em um console Python ou IPython". Basicamente, isso faz del sys.modules[modname] .

Ao tentar executar um script que importa numpy, obtenho um rastreamento de pilha terminando em

[...]
importar numpy como np

Arquivo "C: \ Arquivos de programas \ Python35 \ lib \ site-packagesnumpy \ __ init__.py", linha 142, em
a partir de . importar núcleo

Arquivo "C: \ Arquivos de programas \ Python35 \ lib \ site-packagesnumpy \ core \ __ init__.py", linha 17, em
a partir de . importar multiarray

Arquivo "C: \ Arquivos de programas \ Python35 \ lib \ site-packagesnumpy \ core \ multiarray.py", linha 14, em
a partir de . substituições de importação

Arquivo "C: \ Arquivos de programas \ Python35 \ lib \ site-packagesnumpy \ core \ overrides.py", linha 47, em
"" ")

RuntimeError: o método implement_array_function já tem uma docstring

Acontece comigo também (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
entorpecido: 1.17.2

O verdadeiro problema aqui é que o NumPy não suporta ser reinicializado no processo. Isso remonta ao gh-665 de 2012. Resolver isso exigiria capturar cuidadosamente todo o estado global que criamos em uma estrutura e acessá-lo por meio de um getter no módulo.

Oh, globais. Esses são sempre divertidos.

Downgrade de numpy para numpy == 1.15.4 funcionou para mim.

Downgrade de numpy para numpy == 1.15.4 funcionou para mim.

Esta versão do numpy (1.15.4) funciona com a versão bruxa dos pandas?
Porque com pandas 1.0.3 =
ValueError: numpy.ufunc size changed, may indicate binary incompatibility. Expected 216 from C header, got 192 from PyObject

Outra pergunta, você acha que esse bug será corrigido em breve?

Muito obrigado.

Outra pergunta, você acha que esse bug será corrigido em breve?

Se por "este bug" você quer dizer permitir que o numpy seja excluído e reimportado, a resposta é "Não está em nosso roteiro". Este é um código aberto, então qualquer pessoa pode contribuir para consertá-lo, mas será uma tarefa bastante grande.

Se tudo o que você tem é um aviso de importação, você pode ignorá-lo. Mas eu acho que você está usando uwsgi ...

Se isso for devido ao uwsgi, então só tenho a resposta de que não o apoiaremos e você teria que fazer um esforço muito significativo para isso. No momento, nem mesmo todo o Python oferece suporte para isso, eles estão trabalhando nisso com uma vaga esperança de que um dia funcione. Mas pedir que façamos esse trabalho simplesmente não levará a lugar nenhum. Claro, você pode tentar investir tempo e dinheiro para melhorar a situação, isso é bem-vindo, mas não tenha muita esperança.

Depois que o Python resolver seus problemas (isso pode demorar um pouco, eles estão trabalhando nisso por muitos anos) e houver uma base de usuários razoavelmente grande, pode haver algum interesse nele.
No momento, temos uma API pública que, pelo meu conhecimento, é fundamentalmente incompatível com o que o wsgi faz (usa subinterpretadores) e provavelmente temos alguns caches otimizados que provavelmente queremos e o Python, pelo que sei, ainda não fornece nenhum mecanismo para fazer eles rapidamente neste cenário .

O fato é que os subinterpretadores que o wsgi usa por padrão simplesmente não são suportados por um tamanho razoável do sistema de extensão C. E isso não vai acontecer no futuro previsível. E se alguém pensa ou espera que isso seja uma coisa importante do roteiro do NumPy, então, em minha opinião, os desenvolvedores de Python interpretaram erroneamente (e eu já disse isso, e parecia ser reconhecido lá). Porque eles devem dizer a todos que os sub-intérpretes devem ser presumidos para falhar terrivelmente com a grande maioria das extensões C, que ninguém deve esperar que a situação mude a médio prazo (próximos anos) e, basicamente, que o recurso é experimental quando trata-se de suporte de extensão C.

Sim, muitos desenvolvedores principais do Python estão felizmente se movendo na direção de fazer as coisas funcionarem, mas da perspectiva de um projeto como o NumPy, o suporte a sub-intérpretes (padrões wsgi) não é mais fácil do que a transição de Python 2 para Python 3 com uma fração de usuários em potencial e atualmente nem mesmo a tecnologia para dar suporte a tudo adequadamente!

Então, depois desse discurso retórico ... Vou encerrar isso, se alguém quiser se esforçar para fazer o NumPy funcionar (melhor com sub-intérpretes), esse é um esforço nobre. E estou feliz em ser provado que estou errado ... Mas eu defendo o ponto que sub-intérpretes (wsgi), deve ser considerado um recurso experimental . Ou seja, se você usa subinterpretadores, é mais parecido com o uso de alguma implementação periférica do Python (como um PyPy antigo). E levou anos até que alguém usando PyPy esperasse executar o NumPy dentro do PyPy (e o PyPy fez todo o trabalho para fazer isso acontecer) ...

Eh, eu concordo totalmente que não nos importamos com subinterpretadores (pelo menos), mas este é um problema mais simples - funcionou no 1.15.4 e os relatórios do Django, Spyder, etc. não envolvem uwsgi . Farei uma rápida tentativa de alterar o anexo de docstring em __array_function__ .

True perdeu aqueles. Embora eu também me pergunte lá ... deve ser bastante seguro nesse contexto. No sentido de que, esperançosamente, apenas vaza memória. (Eu ainda me pergunto se o Spyder não deveria simplesmente pular os módulos de extensão C, pelo menos até que o CPython consiga mais máquinas para dizer que um módulo de extensão C o implementa com segurança ... E mesmo assim, para a maioria dos módulos de extensão C recarregando provavelmente não faz quase nada).

E mesmo assim, para a maioria dos módulos de extensão C, recarregar provavelmente não faz quase nada).

Não acho que seja esse o ponto. É muito mais fácil dizer reload(any_module) do que descobrir antes de tentar se há alguma extensão compilada por aí como parte de um pacote Python.

Não tenho certeza do que o Django faz exatamente, mas provavelmente é semelhante.

Eu não queria te incomodar muito.

Eu tenho um serviço da web que usa Flask e Numpy, acho que não sou o único.
Não tenho erros com o servidor de desenvolvimento (certamente Werkzeug) incluído no Flask.

E, de fato, na produção, eu uso o módulo WSGI apache2 para Python3, que me permite manter a carga (vários threads)

Estou aberto, diga-me o que usar:

• Gunicorn ou outro servidor? mas isso também é WSGI
• mod_wsgi-express ?
• ou que opção devo mudar no mod_wsgi ?, li isso nos subinterpretadores do parágrafo na documentação do modwsgi: WSGIApplicationGroup% {GLOBAL}

Muito obrigado.

Qualquer coisa no parágrafo do sub-intérprete deve ser um bom conselho com relação ao NumPy. Não posso dar nenhum conselho sobre o que pode funcionar para serviços da web, mas talvez outra pessoa neste tópico possa.

Eu só queria deixar claro que tornar a situação um pouco melhor pode ser bom (e ajudar alguns), mas não resolverá os problemas mais profundos no futuro previsível. Em qualquer caso, acho que podemos tentar remover essa falha, mas, em vez disso, daremos um grande aviso de que isso pode levar a problemas difíceis de depurar.

Talvez ajude alguém, pois não foi mencionado antes:
Estou usando uwsgi (com Nginx) eo "-intérprete única = true" config ini (ou chave --single-intérprete) resolveu este problema para mim.

Aqui encontrei a explicação deste sinalizador:

Por padrão, o uWSGI executará o código Python em um subinterpretador do processo, em vez do interpretador Python principal criado quando o Python é inicializado pela primeira vez. Isso é feito para permitir que vários aplicativos da web Python separados sejam executados dentro de um processo, mas sejam suficientemente separados para não interferirem uns com os outros. Versões mais antigas do uWSGI podem falhar, no entanto, ao usar sub-intérpretes com threading ativado. Portanto, é mais seguro usar essa opção e restringir-se a um único aplicativo da web por processo. Executar um único aplicativo da web em cada processo com uWSGI é o caso de uso normal, portanto, é improvável que essa restrição seja um problema.

Portanto, como alternativa, você pode alternar para uwsgi com esta configuração ou tentar encontrar algo semelhante para o seu ambiente.

Será reaberto até que realmente fundamos uma correção / solução alternativa - deve ser em breve.

Eu tive esse mesmo erro me ocorrendo ontem, e eu simplesmente não conseguia descobrir o que tinha acontecido. Para completar, terei minha causa aqui: eu tinha um módulo logger, denominado logger.py, que estava sobrescrevendo algo dentro do Numpy. Mudou o nome do módulo, sem erros. Talvez outra pessoa descubra este comentário e descubra que algo semelhante está acontecendo com ela.

Adotamos uma correção para 1.19. Ou talvez uma solução alternativa, já que o erro ainda indica que algo está acontecendo que pode criar problemas.

@seberg com a solução alternativa em 1.19, devemos fechar isso?