Making PEP 3156 (asyncio) non-provisional
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)
On 8 September 2016 at 04:31, Guido van Rossum <guido@python.org> wrote:
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.
This could also be useful in general in terms of defining more clearly what kinds of access to asyncio internals are currently needed to implement 3rd party Transport classes, and perhaps lead to related future additions to the public API. Pending Amber's response, a definite thumbs up from me for removing the provisional caveat, and congratulations on a provisional experiment proving successful :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Wed, Sep 7, 2016 at 8:43 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 8 September 2016 at 04:31, Guido van Rossum <guido@python.org> wrote:
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.
This could also be useful in general in terms of defining more clearly what kinds of access to asyncio internals are currently needed to implement 3rd party Transport classes, and perhaps lead to related future additions to the public API.
Well, the thing is, I don't ever want third party code to subclass any of the implementation classes in asyncio. Even with the best intentions, the implementation details just move around too much and having to worry about subclasses using a "protected" API would stifle improvements completely. A 3rd party Transport class will have to reimplement a bunch of Transport logic that already exists in the asyncio library, but with one exception (in _SelectorTransport.__repr__(), self._loop._selector is used to render the polling state) it doesn't use any internals from the event loop. I expect it would be a major design exercise to create a set of helper APIs or a standard base class that we feel comfortable with providing to transports; especially since creating a new transport often involves exploring new territory in some other domain as well (e.g. I remember that designing the subprocess transports was a complex task). For the add-on starttls package I propose to cheat, because it is on its way to become a stdlib API -- it just needs time to mature and I don't trust that the 3.6 beta period is enough for that. I want at least two independent developers (not Yury or myself) to build a protocol implementation based on the 3rd party starttls package before I'll feel comfortable that the API is right. For example -- do streams need starttls capability? It's somewhat scary because of the buffering, but maybe streams are the right abstraction for protocol implementations. Or maybe now. Nobody knows!
Pending Amber's response, a definite thumbs up from me for removing the provisional caveat, and congratulations on a provisional experiment proving successful :)
Yup. And many new experiments are currently starting! -- --Guido van Rossum (python.org/~guido)
participants (2)
-
Guido van Rossum -
Nick Coghlan