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

Guido van Rossum guido at python.org
Wed Sep 7 14:31:16 EDT 2016

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)

More information about the Python-Dev mailing list