<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Sat, Oct 27, 2018 at 7:16 PM Nathaniel Smith <<a href="mailto:njs@pobox.com">njs@pobox.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The WSGI PEP is a bit of a funny thing, since it's a PEP that doesn't<br>
really involve the language or stdlib. (I guess there's wsgiref, but I<br>
don't think it being in the stdlib actually affects much these days.)<br></blockquote><div><br></div><div>Right. This is why I think I'm unsure quite how to approach replacing it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
What are you hoping to accomplish by making ASGI a PEP?<br></blockquote><div><br></div><div>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. Obviously this is not required for things to function and people to develop against it, but it wasn't required for WSGI either, so in some ways the reason I think it should be a PEP is pretty much purely because WSGI is.</div><div><br></div><div>Andrew</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Sat, Oct 27, 2018 at 4:42 PM, Andrew Godwin <<a href="mailto:andrew@aeracode.org" target="_blank">andrew@aeracode.org</a>> wrote:<br>
> Hi everyone,<br>
><br>
> I'd like to breach the topic of standardising an asynchronous successor to<br>
> WSGI - specifically, the ASGI specification I and a group of other Python<br>
> web developers have been refining over the past couple of years (you can<br>
> read more at <a href="https://asgi.readthedocs.io/en/latest/" rel="noreferrer" target="_blank">https://asgi.readthedocs.io/en/latest/</a>).<br>
><br>
> I'm unsure of the best approach to take for this, given a couple of factors:<br>
><br>
>  - Web SIG has been basically dead for at least two years and several<br>
> maintainers I know unsubscribed from it last time as things got toxic. It<br>
> appears to not be a good place to start this discussion, but maybe it can be<br>
> revived?<br>
><br>
>  - The specification as I would propose it is two or three parts - an<br>
> overall interface for asynchronous servers to talk to applications and then<br>
> a separate specification(s) of how to transport HTTP and WebSockets over<br>
> that. Would this be multiple PEPs?<br>
><br>
> I'd appreciate advice from you all on these questions as well as what you<br>
> think the best way to even approach something like "let's add a WSGI<br>
> successor" is.<br>
><br>
> My initial approach was to go away and prove something in real-world use and<br>
> across a variety of frameworks, and we seem to have got to that point, and<br>
> so now I would like to start making it more official.<br>
><br>
> I'm more than ready to take the specification we have and start prepping it<br>
> to land into the PEP repo for further discussion, but I wanted to check in<br>
> here first before jumping the gun (and besides, there's already plenty of<br>
> specs, write ups, and reference code to discuss the merits of this).<br>
><br>
> Andrew<br>
><br>
> _______________________________________________<br>
> Python-ideas mailing list<br>
> <a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
> Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
><br>
<br>
<br>
<br>
-- <br>
Nathaniel J. Smith -- <a href="https://vorpus.org" rel="noreferrer" target="_blank">https://vorpus.org</a><br>
</blockquote></div></div>