<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, 27 Aug 2015 at 14:16 Yury Selivanov <<a href="mailto:yselivanov.ml@gmail.com">yselivanov.ml@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Recently, in an asyncio related issue [1], Guido said that new features<br>
for asyncio have to wait till 3.6, since asyncio is no longer a provisional<br>
package.  Later, in an off-list conversation, he suggested that this topic<br>
should be discussed on python-dev, and that it might indeed make sense to<br>
either write a new PEP for cases like this or to augment PEP 411.<br>
<br>
My opinion on this topic is that we must maintain full backwards<br>
compatibility for asyncio from 3.5.0, as it is now widely used, and there<br>
is quite a big ecosystem around it.  However, asyncio is simply not mature<br>
enough to be completely feature frozen for about 2 years.<br>
<br>
For example, there is an issue [2] to add starttls support to asyncio.  It<br>
is an essential feature, because some protocols start as clear text and<br>
upgrade to TLS later, for example PostgreSQL PQ3 protocol.  It's very hard<br>
to implement starttls on top of asyncio, lots of code will have to be<br>
duplicated -- it's a feature that has to implemented in the asyncio core.<br>
<br>
Aside from adding new APIs, we also have to improve debugging<br>
capabilities.  One example is using os.fork() from within a running event<br>
loop -- it must be avoided by all means.  There are safe ways to fork in<br>
asyncio applications (and I plan to document them soon), but asyncio<br>
should raise an exception in debug mode if this happens (see issue [3]).<br>
<br>
These are just two immediate issues that I have in mind.  In reality,<br>
asyncio is quite young compared to frameworks like Twisted, which had<br>
years to mature, and accumulate essential features.<br>
<br>
My proposal is to amend PEP 411 with two levels of provisional packages:<br>
<br>
Level 1: Backwards incompatible changes might be introduced in point<br>
releases.<br>
<br>
Level 2: Only backwards compatible changes can be introduced in new point<br>
releases.<br></blockquote><div><br></div><div>How is this any different from the normal compatibility promise we have for any non-provisional code in the stdlib?</div><div><br></div><div>And by point release I assume you mean a new minor release, e.g. 3.5 -> 3.6.</div></div></div>