<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sun, Oct 28, 2018 at 7:35 AM M.-A. Lemburg <<a href="mailto:mal@egenix.com">mal@egenix.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 28.10.2018 05:15, Andrew Godwin wrote:<br>
> Right. This is why I think I'm unsure quite how to approach replacing it.<br>
  <br>
Why would you want to replace it, if what you have in mind is a<br>
different standard for a different audience and use case ?<br>
<br>
WSGI is not going to go away as a standard since it is useful<br>
and works well in the context of non-async web applications.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>ASGI is designed to be able to encapsulate WSGI applications if desired for backwards compatibility, but I wouldn't expect it to "replace" it per se for a long time, if ever.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
You'll win more fans for ASGI by not going confrontational,<br>
since that just sidetracks discussions into non-productive<br>
terrains.<br></blockquote><div><br></div><div>Oh totally. I'm not here to argue, just to work out how to best get to a Python-wide standard we can all benefit from in the same way as WSGI.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Essentially to put it on the same platform as things like WSGI and<br>
> DBAPI2 - to have a directly accepted standard that forms part of the<br>
> language core. Obviously this is not required for things to function and<br>
> people to develop against it, but it wasn't required for WSGI either, so<br>
> in some ways the reason I think it should be a PEP is pretty much purely<br>
> because WSGI is.<br>
<br>
It's a good idea to turn this into an informational PEP similar<br>
to the DB API. These standards are developed outside the usual<br>
Python development process, but provide good guidance for the<br>
Python community at large.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Andrew </div></div></div>