Werkzeug: Suposição incorreta em werkzeug.serving sobre o comportamento do soquete

Embora você provavelmente esteja correto (não tenha feito nenhuma pesquisa), observe que o servidor de Werkzeug destina-se apenas ao desenvolvimento. Executá-lo no Docker e com gevent me leva a acreditar que você não o usa para esse fim.

Na verdade, tenho usado o docker para desenvolvimento e parte do código usado gevent monkeypatches de maneira bastante frívola.
Eu provavelmente nem perceberia se não quebrasse o dontpanic :3

Eu experimentei esse bug no Python 3.5, mas apenas ao definir o soquete subjacente para o modo sem bloqueio (por exemplo, com settimeout ). Acontece que isso é de fato causado por um bug upstream no Python 3: issue24291 . O problema foi corrigido no Python 3.6 (consulte issue26721 )

Uma solução alternativa que foi implementada em outros servidores web é envolver o wfile em um io.BufferedWriter (por exemplo, no wsgiref do CPython em 3.5 ) ou alterar o wbufsize para habilitar o buffer por padrão (por exemplo, veja este problema gevent )

Não tenho certeza se o werkzeug deseja implementar uma solução alternativa também ou se considera um problema não-werkzeug.

com base nas informações fornecidas, acredito que isso realmente seja um bug gevent ou um bug stdlib, werkzeug usa write + flush em um suposto arquivo em buffer, que por sua vez deve sempre funcionar, agora me pergunto se isso também acontece em python simples, ou apenas em gevent

@RonnyPfannschmidt sim, eu entendo sem gevent também, eu só preciso usar um soquete sem bloqueio em combinação com WSGIRequestHandler de werkzeug. Gevent foi apenas mais um exemplo dos muitos projetos que são indiretamente afetados pelo bug upstream no Python 3.5 :-)

Dadas as circunstâncias em que isso acontece, bem como o fato de ser corrigido no Python 3.5 (3.4 entra em EOL em março), estou fechando isso.