Werkzeug: Неверное предположение в werkzeug.serving о поведении сокета

Хотя вы, вероятно, правы (не проводили никаких исследований), обратите внимание, что сервер Werkzeug предназначен только для разработки. Запуск его в Docker и с gevent заставляет меня поверить, что вы не используете его для этой цели.

На самом деле я использовал докер для разработки, и часть кода довольно легкомысленно использовала gevent monkeypatches.
Я бы, наверное, даже не заметил, если бы он не сломался dontpanic :3

Я столкнулся с этой ошибкой в ​​Python 3.5, но только при установке базового сокета в неблокирующий режим (например, с settimeout ). Оказывается, это на самом деле вызвано ошибкой восходящего потока в Python 3: issue24291 . Проблема исправлена ​​в Python 3.6 (см. issue26721 ).

Обходной путь, который был реализован на других веб-серверах, состоит в том, чтобы обернуть wfile в io.BufferedWriter (например, в wsgiref CPython в 3.5 ) или изменить wbufsize , чтобы включить буферизацию с помощью по умолчанию (например, см. этот выпуск gevent )

Не уверен, хочет ли werkzeug также реализовать обходной путь или считает это проблемой, не связанной с werkzeug.

основываясь на предоставленной информации, я считаю, что это действительно либо ошибка gevent, либо ошибка stdlib, werkzeug использует запись + сброс в предполагаемом буферизованном файле, который, в свою очередь, всегда должен работать, теперь мне интересно, происходит ли это также на обычном питоне или только на гевенте

@RonnyPfannschmidt да, я тоже получаю это без gevent , мне просто нужно использовать неблокирующий сокет в сочетании с WSGIRequestHandler werkzeug. Gevent был просто еще одним примером многих проектов, которые косвенно затронуты ошибкой основной ветки разработки в Python 3.5 :-)

Учитывая обстоятельства, в которых это происходит, а также тот факт, что это исправлено в Python 3.5 (3.4 выходит из строя в марте), я закрываю это.