Werkzeug: werkzeug는 ASGI를 지원할 계획이 있습니까?

예, Werkzeug와 Flask는 결국 ASGI를 지원할 것입니다. 이에 대한 일정은 없지만 누군가 PR을 시작했다면 기꺼이 검토하는 데 도움을 드리겠습니다.

그러나 나는 그것을 구현하는 사람이 아니므로 커뮤니티의 도움이 필요합니다. 아래의 최신 업데이트를 참조하십시오. https://github.com/pallets/werkzeug/issues/1322#issuecomment -600926145

이 작업에 관심이 있습니다.

일부 작동하지만 해킹된 ASGI 지원이 진행 중입니다: werkzeug , flask . 더 진행하기 전에 가지고 계신 계획에 대해 더 알고 싶습니다.

내가 거기에서 한 모든 것이 일반적으로 더 좋을 수 있다는 사실을 넘어서 이미 나에게 일어나는 일:

• 저는 스레드에서 동기 코드를 실행하여 양식 파서를 지원하고 있습니다(데이터를 비동기적으로 읽는 동안 차단). 나는 이것이 할 것이라고 생각하지 않습니다. 내가 선호하는 접근 방식은 IO를 제외하는 것입니다.
• 컨텍스트 로컬 지원은 매우 취약합니다. 이 작업을 수행하는 올바른 방법 이 있는 것처럼 보이지만 글로벌 상태를 방해하는 것과 관련이 있으며 특히 ASGI에서는 우리가 세계를 소유하고 있다고 가정할 수 없습니다.
• ASGI에서 실행할 때 동기 함수에 대한 요청 시 양식 데이터를 구문 분석하는 확실한 방법은 없습니다. 보기 기능이 비동기식이라는 것을 알 수 없다면 양식 데이터를 열심히 구문 분석하는 것을 고려해 볼 가치가 있습니다. 기본값이 무엇이든 간에 이를 재정의할 데코레이터가 분명히 있을 수 있습니다.

당신의 생각을 저에게 말 해주세요.

저는 스레드에서 동기 코드를 실행하여 양식 파서를 지원하고 있습니다(데이터를 비동기적으로 읽는 동안 차단). 나는 이것이 할 것이라고 생각하지 않습니다. 내가 선호하는 접근 방식은 IO를 제외하는 것입니다.

가벼운 터치 접근 방식은 기존 파서를 다시 구현하지만 비동기 IO를 사용하는 것입니다. 두 개의 파서 클래스가 후드 아래에서 공통 sans-IO 구현을 공유할 수 있다면 더 깨끗하겠지만 기존 구현을 복제하고 약간 수정하는 것이 더 실용적일 수 있습니다.

컨텍스트 로컬 지원은 매우 취약합니다.

컨텍스트 로컬(asyncio용)은 3.7 stdlib에 있습니다. https://docs.python.org/3.7/library/contextvars.html
이전 버전의 Python을 지원하기 위해 선택적 compat 라이브러리와 함께 사용하는 것 같습니다. (또는 Flask의 ASGI가 3.7 이상이 될 것이라고 가정하십시오)

werkzeug는 스레드 로컬을 사용합니까? (나는 Flask가 한다는 것을 알고 있습니다)

ASGI에서 실행할 때 동기 함수에 대한 요청 시 양식 데이터를 구문 분석하는 확실한 방법이 없습니다.

양식 데이터를 구문 분석하기 위한 동기 인터페이스를 제공하지 않는 것이 좋습니다. (또는 어떤 식으로든 요청 본문에 액세스하기 위해) 대신 비동기 API를 제공합니다. 여기에서 몇 가지 예를 보려면 Starlette의 API를 참조하세요. https://github.com/encode/starlette#body

Python 3.7이 나왔기 때문에 다른 코드가 영향을 받지 않는 한 Python 3.7이 필요한 비동기 기능을 사용하는 것을 반대하지 않습니다. 그러나 기본 3.7 솔루션만큼 좋은 백포트가 있다면 더 좋습니다!

비동기 양식 데이터 구문 분석에 관해서는... 비동기 함수에서 await request.parse() 와 같은 것으로 충분할 것 같은데 구문 분석되지 않은 양식 데이터에 액세스하려고 할 때 예외가 발생합니까?

물론입니다. 또는 $ values = await request.values() values = await request.values values 및 친구를 비동기식으로 만듭니다.

사이에 할당하지 않고 dict 요소를 직접 가져오는 동안 비동기 호출을 수행하려면 (await request.form)['foo'] 와 같은 다소 추한 것이 필요하지 않습니까?

네 :(

그러나 그것이 특히 피할 수 있는지 확실하지 않습니다. 나는 생각하지 않는다

form = await request.form
form['foo']

정말 그 이상도 이하도 아니다.

await request.parse()
request.form['foo']

그것은 분명히 취향에 따라 달라질 수 있지만.

나는 우리가 _members_가 모두 비동기화되는 "비동기 사전"을 대신 발명할 수도 있다고 생각합니다.

물론, 아니면 값과 친구를 비동기식으로 만드십시오. values ​​= await request.values ​​또는 values ​​= await request.values(), 주로 어느 것이 더 좋아 보이는지에 따라 다릅니다.

속성보다는 I/O 수행 작업에 대한 함수 호출을 사용하는 것이 좋습니다.

(await request.form)['foo'] 와 같은 다소 추한 것이 필요하지 않습니까? 사이에 할당하지 않고 dict 요소를 직접 가져오는 동안 비동기 호출을 수행하려면?

어깨를 으쓱 - 하지 마세요.

asyncio는 코드베이스의 어느 부분이 I/O를 수행하는지에 대해 반드시 더 명시적이므로 이를 별도의 줄로 나누는 경향이 있습니다.

form = await request.form()
form['foo']

비동기 지원을 추가하는 데 찬성하지만 여전히 Python 2 및 동기화 버전을 중단할 수 없습니다. @njsmith 에게 들은 한 가지 접근 방식은 모든 것을 비동기식으로 작성한 다음 2to3과 유사한 도구를 사용하여 동기화 버전을 생성하는 것입니다. 분명히 그것은 urllib3에서 시도되고 있지만 그것에 대해 충분히 모릅니다.

request.form 등 뒤에 있는 개체에 마법을 추가할 수 있는지 궁금합니다. 그래서 호출하면 비동기 작업을 수행하는 반면 일반적인 dict-like 메서드는 동기화되고 비동기 모드에서는 실패합니다. 또는 비동기 모드에서 request.form 등에 대한 액세스에 실패하고 비동기 버전에 대해 별도의 이름을 사용할 수 있습니다(예: request.parse_form() ).

또는... request_class = AsyncRequest 비동기를 원하는 경우; 이것은 실제로 AsyncFlask 클래스의 기본값이 될 수 있습니다.

또는... request_class = 누군가가 비동기를 원하는 경우 AsyncRequest; 이것은 실제로 AsyncFlask 클래스의 기본값이 될 수 있습니다.

그것은 나에게 의미가 있는 접근 방식입니다. 네.

폼 파서에 관해서는 #1330에서 sansio-ing을 시도했습니다.

https://github.com/andrew-d/python-multipart 에 100% 적용 범위의 스트리밍 양식 파서 구현도 있습니다. (다른 하나를 찾았지만 "피드 데이터, 이벤트 처리" 흐름에 쉽게 적응할 수 있는지 명확하지 않았습니다.)

python-multipart 는 현재 Starlette에 사용 중인 라이브러리입니다. 여기에서 비동기 스트림과의 통합을 살펴볼 수 있습니다. https://github.com/encode/starlette/blob/master/starlette/formparsers.py#L207

나는 또한 동기화 및 비동기 호환 인터페이스를 제공하는 가장 좋은 방법에 대해 생각하고 있습니다. Starlette에 대해서도 그렇게 하기를 원하기 때문입니다(Werkzeug와 다른 방향으로 가고 있지만 저에게는 "기존 비동기 인터페이스가 있습니다. 어떻게 해야 이제 동기화 항목도 표시하십시오.")

Starlette의 경우 실제 구문 분석을 async parse(self) 메서드로 푸시하고 일반적으로 요청 디스패치 중 언젠가는 호출하지만 일반 일반 속성 form , files 등을 노출합니다. ... 사용자 코드에서 결과에 액세스합니다.

주제에서 벗어나지만 인기 있는 ASGI 및 werkzeug 사례와 관련이 있습니다(이 문제를 탈선시키고 싶지 않지만 추가할 내용 없이 중복 문제를 만들고 싶지는 않음).

https://github.com/django-extensions/django-extensions with ./manage.py runserver_plus 및 https://github.com/django/channels(ASGI 사용)를 실행 중인 경우 Opcode -1 인스펙터에서 ./manage.py runserver 를 실행해 보세요.

(Werkzeug는 django-extensions가 있는 Django의 후드 아래에서 사용되며 디버깅을 위해 runserver_plus 로 개발하는 데 너무 익숙해서 몇 시간 동안 이유를 알아냈습니다.)

개발에서 https를 사용할 수 있도록 runserver_plus를 사용합니다.
이제 Django 채널을 사용하여 Websockets 지원을 추가하려고 하는데 채널이 runserver를 사용하고 runserver_plus를 지원하지 않는다는 문제가 발생했습니다. 따라서 채널을 사용할 수도 있고 https를 사용할 수도 있습니다. 둘 다 사용할 수는 없습니다!

@davidism 이 주제에 대한 마지막 답변 이후 Flask에 대한 ASGI 지원 구현에 변경 사항이 있는지, Python 2에 대한 지원을 종료하기 위해 이 작업과 관련하여 계획이 변경되었는지 여부를 알려주십시오.

2018년 7월 2일 @davidism 은 다음과 같이 씁니다.

분명히 그것은 urllib3에서 시도되고 있지만 그것에 대해 충분히 모릅니다.

얼마 전에 이것을 보았습니다. 누군가 더 배우고 싶다면 python-trio/urllib3#1에 많은 세부 정보가 있는 것 같습니다. 다음을 포함하는 urllib3/urllib3#1323에 대한 링크를 확인하세요.

솔루션: 우리는 async/await 주석이 있는 버전의 코드 복사본을 유지하고 약간의 스크립트가 동기 복사본을 자동으로 다시 제거하여 유지합니다. 아름답지는 않지만 모든 대안이 더 나쁘다고 말할 수 있는 한...

(관심 있으면 거기에서 계속 읽으십시오.)

https://github.com/python-trio/urllib3/commits/bleach-spike에서 꾸준한 진행을 바탕으로 이것이 계속해서 잘 작동하고 있는 것을 보니 반갑습니다.

이 문제를 다시 레이더에 올리기 위한 작은 범프. 올해 3.5가 EOL에 도달하면 비동기 지원에 대해 생각하기 시작하기에 좋은 시기라고 생각합니다.

이 글이 게시된 지 1년 반이 지났지만 이를 구현하기 위한 활동이 많지 않았습니다. 나는 개인적으로 asyncio에 대한 경험이나 필요성이 없으며 ASGI를 좋아하지만 결코 나 자신을 맡을 일이 아닙니다.

그 사이 Quart의 저자인 @pgjones 는 Werkzeug에 더 많이 관여하게 되었습니다. Quart는 이제 가능한 한 배후에서 Werkzeug를 사용하고 있으며 계속해서 개발하고 있습니다. ASGI를 사용하는 것에 대해 Flask 유지 관리자로부터 약간의 반발이 있었기 때문에 Phil은 또한 최소한 async def 기능에 대한 라우팅을 허용하는 팔레트/플라스크#3412를 만들었습니다. 그러나 이는 잠시 동안 중단되었습니다. 이 시점에서 나는 그것에 안주하기보다 ASGI로 가고 싶습니다. @edk0 은 sans-io 형식을 구문 분석하기 위해 #1330을 만들었습니다. 하지만 이 역시 아직 진행 중이며 먼저 더 많은 디자인과 검토를 거쳐야 할 것입니다.

"왜 Flask는 Django가 하는 일을 할 수 없나요?"라고 물을 수 있습니다. 저는 Django 내부 전문가는 아니지만 @andrewgodwin 은 Django가 원래 WSGI에 적응한 방식 때문에 Django가 "더 쉬운"(읽기: 여전히 매우 복잡한) 시간을 갖는다고 설명했습니다. Werkzeug와 Flask가 시작한 매우 WSGI 중심 API입니다. 또한 Django는 Pallets보다 훨씬 더 많은 풀타임 관심과 리소스를 받습니다.

그렇다면 이 문제는 어디에 있습니까? Werkzeug를 사용하는 Flask 호환 프레임워크를 원한다면 Quart를 사용하세요. Quart(또는 Flask)에 기여하여 누락된 부분에서 API 호환성을 높입니다. Werkzeug와 Flask가 ASGI를 지원하도록 하려면 한 단계 더 올라야 합니다. ASGI에 대해 배우기 시작합니다. Werkzeug API의 WSGI 관련 및 차단 부분을 식별하기 시작합니다. WSGI와 ASGI 모두에 대한 구현을 가능하게 하기 위해 만들 수 있는 추상화에 대해 생각하기 시작합니다. 그런 다음 해당 연구를 이 토론으로 가져와서 PR 디자인 및 작성을 시작할 수 있습니다.

Quart 제안에 감사드리며, 이에 대한 기여를 수락하게 되어 매우 기쁩니다.

나는 왜 Flask가 Django가 이 기사 에서 한 일을 할 수 없다고 생각하는지 대답하려고 노력했습니다. 궁극적으로 나는 palettes/flask#3412가 Flask를 위한 최고의 솔루션이라고 생각합니다.

Werkzeug의 관점에서 ASGI가 가능하지만 약간의 고통이 있다고 생각합니다. 고통의 주목할만한 예는 Werkzeug의 많은 것들이 WSGI 호출 가능(예: 예외)이라는 것입니다. ASGI에서는 이 기능을 어떻게 사용할 수 있는지/사용해야 하는지 명확하지 않으므로 제거하는 것이 좋습니다.

내 계획은 Werkzeug를 Quart에 계속 통합하는 것입니다. Werkzeug를 ASGI(sans-io)에 맞게 조정하는 것입니다.