Recently, in an asyncio related issue [1], Guido said that new features for asyncio have to wait till 3.6, since asyncio is no longer a provisional package. Later, in an off-list conversation, he suggested that this topic should be discussed on python-dev, and that it might indeed make sense to either write a new PEP for cases like this or to augment PEP 411. My opinion on this topic is that we must maintain full backwards compatibility for asyncio from 3.5.0, as it is now widely used, and there is quite a big ecosystem around it. However, asyncio is simply not mature enough to be completely feature frozen for about 2 years. For example, there is an issue [2] to add starttls support to asyncio. It is an essential feature, because some protocols start as clear text and upgrade to TLS later, for example PostgreSQL PQ3 protocol. It's very hard to implement starttls on top of asyncio, lots of code will have to be duplicated -- it's a feature that has to implemented in the asyncio core. Aside from adding new APIs, we also have to improve debugging capabilities. One example is using os.fork() from within a running event loop -- it must be avoided by all means. There are safe ways to fork in asyncio applications (and I plan to document them soon), but asyncio should raise an exception in debug mode if this happens (see issue [3]). These are just two immediate issues that I have in mind. In reality, asyncio is quite young compared to frameworks like Twisted, which had years to mature, and accumulate essential features. My proposal is to amend PEP 411 with two levels of provisional packages: Level 1: Backwards incompatible changes might be introduced in point releases. Level 2: Only backwards compatible changes can be introduced in new point releases. With the above amendments, asyncio status should be restated as a level-2 provisional package. I'm CC-ing authors of PEP 411 Nick and Eli. Thank you, Yury [1] http://bugs.python.org/issue23630 [2] http://bugs.python.org/issue23749 [3] http://bugs.python.org/issue21998