ASGIを管理しているのはDjangoのグループ

さて、冒頭でASGIはPEPになっていないと書きました。では私が勘違いした、あのドキュメント郡を管理しているのはどこかというとDjangoのグループです。例えばASGIについて調べるとすぐに見つかるこのドキュメントは右上のEdit on GitHubを確認するとDjangoグループが管理していることが分かります。

Djangoのグループの中でも、特にASGIについて中心的に動いているのはDjangoのコアデベロッパーのAndrew Godwinさんです。Gitの履歴を辿ると、遅くとも日本時間2015年12月23日にはASGIに関する作業を開始していることが分かります。

このころにされたDjango Channelsの最初のコミットからPEPを意識していることが見て取れます。

2018年5月: 今はPEPにする必要はない

最初のコミットから約2年半経過した2018年5月18日、GitHub上でASGIとPEPについてのコメントがあります。

PEP is unnecessary right now as long as there's a clear spec everyone can adhere to.
誰もが遵守できる明確な仕様がある限り、PEPへの参加は今は不要です。

この時点ではPEPにする予定であるが、今ではないと考えていることが分かります。

2018年10月: PEP化に向けた動き

さらに5ヶ月ほど経過した2018年10月、AndrewさんはメーリングリストPython-ideasに件名「Standardising ASGI as a PEP」(PEPとしてASGIの標準化)を投稿をします。

メーリングリストでのやり取りの一部を引用します。

Q. What are you hoping to accomplish by making ASGI a PEP?
ASGIをPEPにすることで何を達成したいのでしょうか。
A. Essentially to put it on the same platform as things like WSGI and DBAPI2 to have a directly accepted standard that forms part of the language core.
WSGIやDBAPI2などと同じ場に置くことで、言語のコアの一部を形成する直接受け入れられた標準にすることです。

Q. Why would you want to replace it, if what you have in mind is a different standard for a different audience and use case? WSGI is not going to go away as a standard since it is useful and works well in the context of non-async web applications.
(WSGIと)異なる利用者やユースケースのための標準ならば、なぜWSGIを置き換えたいのですか？WSGIは非同期ではないウェブアプリケーションのコンテキストでうまく機能しているので、なくならないでしょう。
A. The word "replace" there was maybe not quite right - I think we need an asynchronous equivalent of WSGI for the same reasons we have WSGI (inter-operability between servers, frameworks, and applications). The use case is quite similar, to be honest.
置き換えるという言葉は適切ではありませんでした。WSGIがあるのと同じ理由でWSGI同等の非同期なものが必要と考えていますが、正直なところユースケースはとても似ています。

Q. It's a good idea to turn this into an informational PEP similar to the DB API. These standards are developed outside the usual Python development process, but provide good guidance for the Python community at large.
これをDB APIと同様の情報PEPにすることをお勧めします。これらの標準は通常のPythonの開発プロセスの外で開発されていますが、Pythonコミュニティ全体に良いガイダンスを提供します。
A. I agree - I don't think it makes sense as either of the other options, and both PEP 3333 and PEP 249 are Informational. They're the two most similar things I can think of in the PEP ecosystem.
同意します。他の選択肢は理にかなっていないと思います。PEP 3333とPEP249はどちらも情報提供で、PEPエコシステム内で私が考える最も近いものです。

PEP 249とPEP 3333はそれぞれPython Database API Specification v2.0とPython Web Server Gateway Interface v1.0.1です。

2020年1月: PEP化を思いとどまる

Django 3.0が2019年12月2日にリリースされました。このリリースはASGIを含んでいます。ASGIが今までよりぐっと身近になったこのときは、ASGIをPEPにするのによい機会と私なら思うのですが、そうはなりませんでした。ここで冒頭の発言が出ます。

It's worth noting that I was discouraged from making ASGI a PEP by several Python core developers, which is why I have not been pursuing that process any further. I'm not sure I share this view, so I may come back to it in the future, but there's a reason it's not in the process right now.
何人かのPythonのコアデベロッパーからASGIをPEPにすることを思いとどまらされたのは注目に値します。この見解が共有されているか分からないので、将来的にはPEP化に向けて戻ってくるかもしれませんが、今はその作業は止まっています。

2020年1月28日のメーリングリストの投稿より

先の流れで情報提供(Informational)のPEPになるのだと思っていたので驚きました。

言語仕様に関する事柄ではないのでPEPは必須ではない

WSGIの例があるため、私はASGIもPEPになってしかるべきと考えていました。しかしPEPが「Python Enhancement Proposals」(Python拡張提案)であることを思い出すと、ASGIもWSGIもPython自体の拡張ではないことから、必須ではないと気がつきます。必須なものは例えばPython 3.8で導入された:=(セイウチ演算子)です。これはPython本体の構文が変更になるのですからPEPが必須です。

ASGIのようなPython本体と関係ない話は外でやってくれというのがPython本体のコアデベロッパーたちの意見として出るのは分かります。

そうは言ってもプロトコルの分断を防ぐためにも、Django以外のウェブアプリケーションフレームワークが追従しやすくするためにも、私はPEP化を望みます。もしくはWSGIのPEPが改定されASGI相当のことができるようになることを望みます。PEPになれないのならばDjango以外の組織によって管理されるだけでも、他のフレームワークが追従しやすくなるのではないでしょうか。

私はフレームワークの開発者ではありませんが、ASGIを積極的に取り入れるのは様子を見ようという考えに至りました。

補足: ASGIはDjangoのためのものではない

ASGIは元をたどればDjango Channelsという、DjangoをHTTPだけではなくWebSocketやIoTプロトコルといった領域に拡張するためのプロジェクトが必要に迫られたものです。しかしASGIはDjangoに一切依存していません。