Numpy: RuntimeError:implement_array_function 메소드에 이미 docstring이 있습니다.

꽤 많은 테스트 후에 uwsgi 내에서 실행되는 것과 관련이 있다고 확신합니다.

이것은 막연한 벨을 울립니다. IIRC uwsgi 는 -OO 실행하는 것과 같은 일종의 독스트링 조작을 수행합니다.

이는 Python 콘솔에 IPython을 사용하는 Spyder에서도 발생합니다. 그들은 "파이썬이나 IPython 콘솔에서 파일을 실행할 때 가져온 모듈을 파이썬이 강제로 다시 로드하도록"하는 "사용자 모듈 리로더"라는 기술을 가지고 있습니다. 기본적으로 이것은 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:\Program Files\Python35\lib\site-packagesnumpy\core\multiarray.py", 14행,
에서 . 가져오기 재정의

파일 "C:\Program Files\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

파이썬 7.3.7
숫자: 1.17.2

여기서 진짜 문제는 NumPy가 프로세스에서 다시 초기화되는 것을 지원하지 않는다는 것입니다. 이것은 2012년의 gh-665로 거슬러 올라갑니다. 이 문제를 해결하려면 구조체에서 생성한 모든 전역 상태를 주의 깊게 캡처하고 모듈의 getter를 통해 액세스해야 합니다.

오, 글로벌. 그것들은 항상 재미있습니다.

numpy를 numpy==1.15.4로 다운그레이드하면 트릭이 발생했습니다.

numpy를 numpy==1.15.4로 다운그레이드하면 트릭이 발생했습니다.

이 버전의 numpy(1.15.4)는 pandas의 마녀 버전에서 작동합니까?
팬더 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 에서도 이를 지원하지는 않습니다. 언젠가는 작동할 것이라는 막연한 희망을 가지고 작업하고 있습니다. 그러나 우리에게 이 일을 해달라고 요청하는 것은 아무데도 가지 않을 것입니다. 물론, 상황을 개선하기 위해 시간과 돈을 투자할 수 있습니다. 환영합니다. 하지만 희망을 가지지는 마십시오.

파이썬은 최종 함께 자신의 일을 얻는다 후 (이것은 다소 시간이 걸릴 수 있습니다 그들은 몇 년 동안이 노력하고 있습니다) 거기에 약간의 관심이 될 수 있으며 합리적으로 큰 userbase가가 있습니다.
현재 우리는 wsgi가 하는 일(하위 인터프리터 사용)과 근본적으로 호환되지 않는 공개 API를 갖고 있으며 아마도 우리가 원하는 최적화된 캐시가 있을 수 있으며 Python 은 아직 만들기 위한 메커니즘을 제공하지 않습니다. 이 설정에서 빠르게 .

사실 wsgi가 기본적으로 사용하는 서브 인터프리터는 합리적인 크기의 C 확장 시스템에서 지원되지 않습니다. 그리고 이것은 가까운 장래에 일어나지 않을 것입니다. 그리고 누군가 이것을 NumPy 로드맵의 중요한 것으로 생각하거나 기대한다면, 제 생각에는 Python 개발자가 신호를 잘못 알고 있는 것입니다. 왜냐하면 그들은 서브 인터프리터가 대다수의 C 확장에서 끔찍하게 실패한다고 가정해야 하고, 아무도 상황이 중기(향후 몇 년)에 바뀔 것이라고 예상해서는 안 되며, 기본적으로 이 기능은 다음과 같은 경우 실험적이라는 것을 알려야 하기 때문입니다. 그것은 C 확장 지원에 온다.

예, 많은 Python 핵심 개발자가 작업을 작동시키는 방향으로 행복하게 움직이고 있지만 NumPy와 같은 프로젝트의 관점에서 하위 인터프리터(wsgi 기본값)를 지원하는 것은 잠재적인 사용자와 현재 모든 것을 제대로 지원하는 기술조차 없습니다!

그래서, 이 호언장담 이후에... 누군가 NumPy가 (서브 인터프리터와 함께 더 잘 작동하도록) 노력을 기울이고자 한다면 이것은 고귀한 노력입니다. 그리고 나는 틀렸다는 것이 증명되어 기쁩니다. 그러나 나는 서브 인터프리터(wsgi) 가 실험적이고 기능적인 것으로 간주되어야 한다는 점에 동의

어, 나는 우리가 (아직 어쨌든) 서브 인터프리터에 대해 신경 쓰지 않는다는 데 전적으로 동의하지만 이것은 더 간단한 문제입니다. 1.15.4에서 작동했으며 Django, Spyder 등의 보고서에는 uwsgi 포함되지 않습니다. __array_function__ 의 독스트링 첨부 파일을 빠르게 변경하겠습니다.

사실은 그것들을 놓쳤습니다. 나는 거기에 대해서도 궁금하지만 ... 그 맥락에서 상당히 안전해야합니다. 그것은 희망적으로만 메모리를 누출한다는 의미에서. (최소한 CPython이 C-확장 모듈이 그것을 안전하게 구현한다고 말하는 더 많은 기계를 얻을 때까지 Spyder가 C-확장 모듈을 건너뛰면 안 되는지 약간 궁금합니다... 그리고 대부분의 C-확장 모듈이 다시 로드되는 경우 아마 거의 아무것도 하지 않을 것입니다).

그런 다음에도 대부분의 C 확장 모듈의 경우 재로딩은 거의 아무 것도 하지 않습니다).

그게 핵심이 아닌 것 같아요. reload(any_module) 라고 말하는 것이 Python 패키지의 일부로 컴파일된 확장이 있는지 확인하기 전에 알아내는 것보다 훨씬 쉽습니다.

Django가 정확히 무엇을 하는지는 확실하지 않지만 아마도 비슷할 것입니다.

나는 당신을 너무 귀찮게하고 싶지 않았습니다.

Flask와 Numpy를 사용하는 웹 서비스가 있습니다. 저만 그런 것은 아닌 것 같습니다.
Flask에 포함된 개발 서버(확실히 Werkzeug)에는 오류가 없습니다.

그리고 실제로 프로덕션에서는 Python3용 apache2 WSGI 모듈을 사용하여 로드(여러 스레드)를 유지할 수 있습니다.

열려 있습니다. 무엇을 사용해야 하는지 알려주세요.

• Gunicorn 또는 다른 서버? 하지만 그것도 WSGI
• mod_wsgi 익스프레스 ?
• 또는 mod_wsgi에서 어떤 옵션을 변경해야 합니까?, modwsgi 문서의 단락 하위 인터프리터 에서 읽었습니다 . WSGIApplicationGroup %{GLOBAL}

매우 감사합니다.

하위 인터프리터 단락의 모든 내용은 NumPy와 관련하여 건전한 조언이어야 합니다. 나는 웹 서비스에 어떤 것이 효과가 있을지에 대해 어떤 조언도 할 수 없지만 이 스레드의 다른 누군가는 할 수 있습니다.

상황을 조금 더 좋게 만드는 것이 좋을 수는 있지만(그리고 일부는 도움이 될 수 있음) 가까운 장래에 근본적인 문제를 해결하지 못할 것이라는 점을 분명히 하고 싶었습니다. 어쨌든 우리는 이 실패를 제거하려고 시도할 수 있지만 대신 디버그하기 어려운 문제로 이어질 수 있다는 큰 경고를 줄 것입니다.

이전에 언급되지 않은 것처럼 누군가에게 도움이 될 수 있습니다.
나는 uwsgi (Nginx와 함께)를 사용하고 있으며 " single-interpreter = true " ini config(또는 --single-interpreter 스위치) 가 이 문제를 해결했습니다 .

여기 에서 이 플래그에 대한 설명을 찾았습니다.

기본적으로 uWSGI는 Python이 처음 초기화될 때 생성된 기본 Python 인터프리터가 아닌 프로세스의 하위 인터프리터 내에서 Python 코드를 실행합니다. 이것은 하나의 프로세스 내에서 여러 개의 개별 Python 웹 응용 프로그램을 실행할 수 있지만 서로 간섭하지 않도록 충분히 분리되도록 수행됩니다. 그러나 스레딩이 활성화된 하위 인터프리터를 사용할 때 이전 버전의 uWSGI가 실패할 수 있습니다. 따라서 이 옵션을 사용하고 프로세스당 단일 웹 응용 프로그램으로 제한하는 것이 가장 안전합니다. uWSGI를 사용하여 각 프로세스에서 단일 웹 애플리케이션을 실행하는 것이 일반적인 사용 사례이므로 이 제한이 문제가 될 가능성은 거의 없습니다.

따라서 해결 방법으로 이 구성을 사용하여 uwsgi로 전환하거나 환경에 유사한 것을 찾을 수 있습니다.

수정/해결 방법을 실제로 병합할 때까지 다시 열 예정입니다. 곧 제공될 예정입니다.

어제 같은 오류가 발생했는데 무슨 일이 일어났는지 알 수 없었습니다. 완료를 위해 여기에 내 원인이 있습니다. Numpy 내부의 무언가를 덮어쓰는 logger.py라는 로거 모듈이 있습니다. 모듈 이름을 변경했는데 오류가 없습니다. 아마도 다른 누군가가 이 댓글을 보고 비슷한 일이 그들에게 일어나고 있다는 것을 알아차릴 것입니다.

1.19에 대한 수정 사항을 푸시했습니다. 또는 오류가 여전히 문제를 일으킬 수 있는 일이 진행 중임을 나타내기 때문에 오히려 해결 방법일 수 있습니다.

@seberg 1.19의 해결 방법을 사용하여 이것을 닫아야 합니까?