[Python-Dev] Making PEP 3156 (asyncio) non-provisional

[Guido van Rossum]

PEP 3156 and the asyncio module it defines have been provisional for
the lifetime of Python 3.4 and 3.5. The module is now quite mature. I
propose that we end the provisional period and make asyncio subject to
the usual backwards compatibility rules: new features only appear in
"minor" releases (e.g. 3.6, 3.7) and all changes must be backward
compatible. There's some wiggle room though: in some cases we may
decide that a given "feature" was really "undefined/undocumented
behavior" and then we can treat it as a bug and fix it (== change the
behavior) in a bugfix release (or during the 3.6 beta period).

There are some worries that Twisted might request some incompatible
changes in order to obtain better interoperability. I've sent an email
to Amber Brown asking for a clarification.

There's also the issue of starttls, a feature that we know we'd like
to add but don't have ready for 3.6b1. I think the right approach
there is to provide an add-on package on PyPI that implements a
starttls-capable Transport class, and when that code is sufficiently
battle-tested we can add it to the stdlib (hopefully by 3.7). Such a
package might end up having to copy portions of the asyncio
implementation and/or use internal/undocumented APIs; that's fine
because it is only meant as a temporary measure, and we can make it
clear that just because the starttls package uses a certain internal
API that doesn't mean that API is now public. A big advantage of
having the initial starttls implementation outside the stdlib is that
its release schedule can be much more frequent than that of the stdlib
(== every 6 months), and a security issue in the starttls package
won't require all the heavy guns of doing a security release of all of
CPython.

-- 
--Guido van Rossum (python.org/~guido)