Hi everyone, I'd like to breach the topic of standardising an asynchronous successor to WSGI - specifically, the ASGI specification I and a group of other Python web developers have been refining over the past couple of years (you can read more at https://asgi.readthedocs.io/en/latest/). I'm unsure of the best approach to take for this, given a couple of factors: - Web SIG has been basically dead for at least two years and several maintainers I know unsubscribed from it last time as things got toxic. It appears to not be a good place to start this discussion, but maybe it can be revived? - The specification as I would propose it is two or three parts - an overall interface for asynchronous servers to talk to applications and then a separate specification(s) of how to transport HTTP and WebSockets over that. Would this be multiple PEPs? I'd appreciate advice from you all on these questions as well as what you think the best way to even approach something like "let's add a WSGI successor" is. My initial approach was to go away and prove something in real-world use and across a variety of frameworks, and we seem to have got to that point, and so now I would like to start making it more official. I'm more than ready to take the specification we have and start prepping it to land into the PEP repo for further discussion, but I wanted to check in here first before jumping the gun (and besides, there's already plenty of specs, write ups, and reference code to discuss the merits of this). Andrew
The WSGI PEP is a bit of a funny thing, since it's a PEP that doesn't really involve the language or stdlib. (I guess there's wsgiref, but I don't think it being in the stdlib actually affects much these days.) What are you hoping to accomplish by making ASGI a PEP? -n On Sat, Oct 27, 2018 at 4:42 PM, Andrew Godwin <andrew@aeracode.org> wrote:
Hi everyone,
I'd like to breach the topic of standardising an asynchronous successor to WSGI - specifically, the ASGI specification I and a group of other Python web developers have been refining over the past couple of years (you can read more at https://asgi.readthedocs.io/en/latest/).
I'm unsure of the best approach to take for this, given a couple of factors:
- Web SIG has been basically dead for at least two years and several maintainers I know unsubscribed from it last time as things got toxic. It appears to not be a good place to start this discussion, but maybe it can be revived?
- The specification as I would propose it is two or three parts - an overall interface for asynchronous servers to talk to applications and then a separate specification(s) of how to transport HTTP and WebSockets over that. Would this be multiple PEPs?
I'd appreciate advice from you all on these questions as well as what you think the best way to even approach something like "let's add a WSGI successor" is.
My initial approach was to go away and prove something in real-world use and across a variety of frameworks, and we seem to have got to that point, and so now I would like to start making it more official.
I'm more than ready to take the specification we have and start prepping it to land into the PEP repo for further discussion, but I wanted to check in here first before jumping the gun (and besides, there's already plenty of specs, write ups, and reference code to discuss the merits of this).
Andrew
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- Nathaniel J. Smith -- https://vorpus.org
On Sat, Oct 27, 2018 at 7:16 PM Nathaniel Smith <njs@pobox.com> wrote:
The WSGI PEP is a bit of a funny thing, since it's a PEP that doesn't really involve the language or stdlib. (I guess there's wsgiref, but I don't think it being in the stdlib actually affects much these days.)
Right. This is why I think I'm unsure quite how to approach replacing it.
What are you hoping to accomplish by making ASGI a PEP?
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. Andrew
Hi everyone,
I'd like to breach the topic of standardising an asynchronous successor to WSGI - specifically, the ASGI specification I and a group of other Python web developers have been refining over the past couple of years (you can read more at https://asgi.readthedocs.io/en/latest/).
I'm unsure of the best approach to take for this, given a couple of factors:
- Web SIG has been basically dead for at least two years and several maintainers I know unsubscribed from it last time as things got toxic. It appears to not be a good place to start this discussion, but maybe it can be revived?
- The specification as I would propose it is two or three parts - an overall interface for asynchronous servers to talk to applications and
On Sat, Oct 27, 2018 at 4:42 PM, Andrew Godwin <andrew@aeracode.org> wrote: then
a separate specification(s) of how to transport HTTP and WebSockets over that. Would this be multiple PEPs?
I'd appreciate advice from you all on these questions as well as what you think the best way to even approach something like "let's add a WSGI successor" is.
My initial approach was to go away and prove something in real-world use and across a variety of frameworks, and we seem to have got to that point, and so now I would like to start making it more official.
I'm more than ready to take the specification we have and start prepping it to land into the PEP repo for further discussion, but I wanted to check in here first before jumping the gun (and besides, there's already plenty of specs, write ups, and reference code to discuss the merits of this).
Andrew
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
-- Nathaniel J. Smith -- https://vorpus.org
On 28.10.2018 05:15, Andrew Godwin wrote:
On Sat, Oct 27, 2018 at 7:16 PM Nathaniel Smith <njs@pobox.com <mailto:njs@pobox.com>> wrote:
The WSGI PEP is a bit of a funny thing, since it's a PEP that doesn't really involve the language or stdlib. (I guess there's wsgiref, but I don't think it being in the stdlib actually affects much these days.)
Right. This is why I think I'm unsure quite how to approach replacing it. 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. You'll win more fans for ASGI by not going confrontational, since that just sidetracks discussions into non-productive terrains.
What are you hoping to accomplish by making ASGI a PEP?
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.
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. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Oct 28 2018)
Python Projects, Coaching and Consulting ... http://www.egenix.com/ Python Database Interfaces ... http://products.egenix.com/ Plone/Zope Database Interfaces ... http://zope.egenix.com/
::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/
On Sun, Oct 28, 2018 at 7:35 AM M.-A. Lemburg <mal@egenix.com> wrote:
On 28.10.2018 05:15, Andrew Godwin wrote:
Right. This is why I think I'm unsure quite how to approach replacing it.
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.
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. 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.
You'll win more fans for ASGI by not going confrontational, since that just sidetracks discussions into non-productive terrains.
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.
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.
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.
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. Andrew
participants (3)
-
Andrew Godwin -
M.-A. Lemburg -
Nathaniel Smith