On Wed, Sep 7, 2016 at 8:43 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 8 September 2016 at 04:31, Guido van Rossum <gu...@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) _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
