[Python-Dev] provisional status for asyncio

[Brett Cannon]

On Thu, 27 Aug 2015 at 14:16 Yury Selivanov <yselivanov.ml at gmail.com> wrote:

> 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.
>

How is this any different from the normal compatibility promise we have for
any non-provisional code in the stdlib?

And by point release I assume you mean a new minor release, e.g. 3.5 -> 3.6.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150827/d1564305/attachment.html>