Numpy: RuntimeError: метод implementation_array_function уже имеет строку документации

Созданный на 28 авг. 2019  ·  20Комментарии  ·  Источник: numpy/numpy

Воспроизведение примера кода:

from flask import Flask

import numpy

app = Flask(__name__)

как приложение uwsgi.

Полная среда: https://github.com/luckydonald-archive/numpy-issues-14384/

Сообщение об ошибке:

|> test_bot_1                 | [uWSGI] getting INI configuration from /config/uwsgi.ini
|> test_bot_1                 | *** Starting uWSGI 2.0.18 (64bit) on [Wed Aug 28 00:25:33 2019] ***
|> test_bot_1                 | compiled with version: 6.3.0 20170516 on 04 May 2019 16:28:22
|> test_bot_1                 | os: Linux-4.4.0-75-generic #96-Ubuntu SMP Thu Apr 20 09:56:33 UTC 2017
|> test_bot_1                 | nodename: 2dd932a7998b
|> test_bot_1                 | machine: x86_64
|> test_bot_1                 | clock source: unix
|> test_bot_1                 | pcre jit disabled
|> test_bot_1                 | detected number of CPU cores: 8
|> test_bot_1                 | current working directory: /app
|> test_bot_1                 | detected binary path: /usr/local/bin/uwsgi
|> test_bot_1                 | your processes number limit is 1048576
|> test_bot_1                 | your memory page size is 4096 bytes
|> test_bot_1                 | detected max file descriptor number: 1048576
|> test_bot_1                 | lock engine: pthread robust mutexes
|> test_bot_1                 | thunder lock: disabled (you can enable it with --thunder-lock)
|> test_bot_1                 | uwsgi socket 0 bound to UNIX address /sockets/bots/test_bot.sock fd 3
|> test_bot_1                 | Python version: 3.6.8 (default, Mar 27 2019, 08:49:59)  [GCC 6.3.0 20170516]
|> test_bot_1                 | *** Python threads support is disabled. You can enable it with --enable-threads ***
|> test_bot_1                 | Python main interpreter initialized at 0x55b90bbdc100
|> test_bot_1                 | your server socket listen backlog is limited to 100 connections
|> test_bot_1                 | your mercy for graceful operations on workers is 60 seconds
|> test_bot_1                 | mapped 1239640 bytes (1210 KB) for 16 cores
|> test_bot_1                 | *** Operational MODE: preforking ***
|> test_bot_1                 | WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x55b90bbdc100 pid: 1 (default app)
|> test_bot_1                 | mounting main.py on /test_bot
|> test_bot_1                 | Traceback (most recent call last):
|> test_bot_1                 |   File "main.py", line 3, in <module>
|> test_bot_1                 |     import numpy
|> test_bot_1                 |   File "/usr/local/lib/python3.6/site-packages/numpy/__init__.py", line 142, in <module>
|> test_bot_1                 |     from . import core
|> test_bot_1                 |   File "/usr/local/lib/python3.6/site-packages/numpy/core/__init__.py", line 17, in <module>
|> test_bot_1                 |     from . import multiarray
|> test_bot_1                 |   File "/usr/local/lib/python3.6/site-packages/numpy/core/multiarray.py", line 14, in <module>
|> test_bot_1                 |     from . import overrides
|> test_bot_1                 |   File "/usr/local/lib/python3.6/site-packages/numpy/core/overrides.py", line 47, in <module>
|> test_bot_1                 |     """)
|> test_bot_1                 | RuntimeError: implement_array_function method already has a docstring

Информация о версии Numpy / Python:

Недавно установлен numpy , 28.08.2019.

57 - Close?

Самый полезный комментарий

Понижение numpy до numpy == 1.15.4 помогло мне.

Все 20 Комментарий

После некоторого тестирования я почти уверен, что это связано с запуском в uwsgi .

Это звучит нечетко. IIRC uwsgi выполняет какие-то манипуляции со строкой документации, например, работает с -OO .

Это также происходит в Spyder, который использует IPython для своей консоли Python. У них есть метод, называемый «перезагрузчик пользовательских модулей», который «заставляет Python перезагружать модули, которые были импортированы при выполнении файла в консоли Python или 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, в
из . import multiarray

Файл "C: \ Program Files \ Python35 \ lib \ site-packagesnumpy \ core \ multiarray.py", строка 14, в
из . переопределения импорта

Файл "C: \ Program Files \ Python35 \ lib \ site-packagesnumpy \ core \ overrides.py", строка 47, в
"" ")

RuntimeError: метод implementation_array_function уже имеет строку документации

Со мной тоже бывает (сервер 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
число: 1.17.2

Настоящая проблема здесь в том, что NumPy не поддерживает повторную инициализацию в процессе. Это восходит к gh-665 2012 года. Решение этой проблемы потребует тщательного захвата всего глобального состояния, которое мы создаем в структуре, и доступа к нему через геттер модуля.

О, глобалы. Это всегда весело.

Понижение numpy до numpy == 1.15.4 помогло мне.

Понижение numpy до numpy == 1.15.4 помогло мне.

Эта версия numpy (1.15.4) работает с ведьмой версией панд?
Потому что с пандами 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 поддерживает это, они работают над этим со смутной надеждой, что однажды это сработает. Но просьба сделать эту работу просто никуда не денется. Конечно, вы можете попробовать потратить время и деньги на улучшение ситуации, это приветствуется, но не надейтесь.

После того, как Python соберет свою вещь на своей стороне (это может занять некоторое время, они работают над этим много лет) и появится достаточно большая база пользователей, это может проявить некоторый интерес.
В настоящее время у нас есть общедоступный API, который, насколько мне известно, принципиально несовместим с тем, что делает wsgi (используются суб-интерпретаторы), и у нас, вероятно, есть некоторые оптимизированные кеши, которые мы, вероятно, захотим, а Python, насколько мне известно, еще не предоставляет никакого механизма для создания их быстро в этой обстановке .

Дело в том, что субинтерпретаторы, которые использует wsgi по умолчанию, просто не поддерживаются разумным размером системы расширений C. И этого не произойдет в обозримом будущем. И если кто-то думает или ожидает, что это важная вещь в дорожной карте NumPy, то, на мой взгляд, разработчики Python ошиблись в своих сигналах (и я так сказал, и, похоже, там это признали). Потому что они должны сказать всем, что субинтерпретаторы должны терпеть ужасные неудачи с подавляющим большинством C-расширений, что никто не должен ожидать, что ситуация изменится в среднесрочной перспективе (следующие несколько лет), и что в основном эта функция является экспериментальной, когда речь идет о поддержке C-расширений.

Да, многие разработчики ядра Python с радостью движутся в направлении обеспечения работы, но с точки зрения такого проекта, как NumPy, поддержка суб-интерпретаторов (значения по умолчанию wsgi) не проще, чем переход с Python 2 на Python 3 с долей потенциальные пользователи и в настоящее время даже нет технологии, чтобы должным образом поддерживать все!

Итак, после этой тирады ... Я закрою это, если кто-то хочет потратить усилия на то, чтобы заставить NumPy работать (лучше с субинтерпретаторами), это благородное усилие. И я рад, что ошибся ... Но я придерживаюсь мнения, что суб-интерпретаторы (wsgi) должны рассматриваться как экспериментальные и функциональные . Т.е. если вы используете субинтерпретаторы, это больше похоже на использование какой-то периферийной реализации Python (например, раннего PyPy). И прошли годы, прежде чем кто-либо, использующий PyPy, ожидал запустить NumPy в PyPy (и PyPy сделал всю работу, чтобы это произошло) ...

Эх, я полностью согласен с тем, что нас не волнуют субинтерпретаторы (пока что), но это более простая проблема - она ​​работала в 1.15.4, а отчеты Django, Spyder и т. Д. Не содержат uwsgi . Я быстро изменю прикрепленную строку документации в __array_function__ .

Правда пропустил те. Хотя мне тоже интересно ... в этом контексте это должно быть довольно безопасно. В том смысле, что это, надеюсь, только утечка памяти. (Мне все еще немного интересно, не следует ли Spyder просто пропускать модули C-extension, по крайней мере, до тех пор, пока CPython не получит больше оборудования, чтобы сказать, что модуль C-extension реализует его безопасно ... И даже тогда для большинства модулей C-extension перезагрузка наверное почти ничего не делает).

И даже тогда для большинства модулей C-extension перезагрузка, вероятно, почти ничего не делает).

Не думаю, что дело в этом. Гораздо проще сказать reload(any_module) чем перед попыткой выяснить, есть ли какое-то скомпилированное расширение как часть пакета Python.

Не уверен, что именно делает Django, но, вероятно, похоже.

Я не хотел тебя слишком сильно раздражать.

У меня есть веб-сервис, использующий Flask и Numpy, думаю, я не единственный.
У меня нет ошибок с сервером разработки (конечно, Werkzeug), включенным во Flask.

И действительно, в производстве я использую модуль apache2 WSGI для Python3, который позволяет мне удерживать нагрузку (несколько потоков)

Я открыт, подскажите что использовать:

Большое тебе спасибо.

Все, что находится в абзаце субинтерпретатора, должно быть разумным советом относительно NumPy. Я не могу дать никаких советов о том, что может работать для веб-сервисов, но, возможно, кто-то еще в этой теме может.

Я просто хотел прояснить, что улучшение ситуации может быть хорошим (и некоторым может помочь), но не решит глубинных проблем в обозримом будущем. В любом случае, я думаю, мы можем попытаться устранить этот сбой, но вместо этого сделаем огромное предупреждение о том, что это может привести к трудным для отладки проблемам.

Может быть, это кому-то поможет, о чем раньше не упоминалось:
Я использую uwsgi (с Nginx), и конфигурация ini " single-Interterter = true " (или переключатель --single-Interterter ) решила эту проблему для меня .

Здесь я нашел объяснение этого флага:

По умолчанию uWSGI будет выполнять код Python во вспомогательном интерпретаторе процесса, а не в основном интерпретаторе Python, созданном при первой инициализации Python. Это сделано для того, чтобы в одном процессе можно было запускать несколько отдельных веб-приложений Python, но при этом они должны быть достаточно разделены, чтобы не мешать друг другу. Однако более старые версии uWSGI могут дать сбой при использовании вспомогательных интерпретаторов с включенной потоковой передачей. Поэтому безопаснее всего использовать эту опцию и ограничиться одним веб-приложением для каждого процесса. Запуск одного веб-приложения в каждом процессе с uWSGI является нормальным вариантом использования, поэтому маловероятно, что это ограничение станет проблемой.

В качестве обходного пути вы можете переключиться на uwsgi с этой конфигурацией или попытаться найти что-то подобное для вашей среды.

Будет открыто, пока мы не объединим исправление / обходной путь - скоро должно быть.

Вчера у меня возникла такая же ошибка, и я просто не мог понять, что произошло. Ради завершения, у меня была причина: у меня был модуль логгера с именем logger.py, который перезаписывал что-то внутри Numpy. Сменил название модуля, ошибок нет. Может быть, кто-то еще наткнется на этот комментарий и поймет, что с ним происходит что-то подобное.

Мы выпустили исправление для версии 1.19. Или, может быть, обходной путь, поскольку ошибка по-прежнему указывает на то, что что-то происходит, что может создать проблемы.

@seberg с обходным

Была ли эта страница полезной?
0 / 5 - 0 рейтинги

Смежные вопросы

marcocaccin picture marcocaccin  ·  4Комментарии

kevinzhai80 picture kevinzhai80  ·  4Комментарии

thouis picture thouis  ·  4Комментарии

keithbriggs picture keithbriggs  ·  3Комментарии

astrofrog picture astrofrog  ·  4Комментарии