On 15 March 2014 21:02, Giampaolo Rodola' <g.rodola@gmail.com> wrote:
On Sat, Mar 15, 2014 at 3:17 AM, Guido van Rossum <guido@python.org> wrote:
I don't think so. asyncio depends on selectors but not vice versa. The selectors module was not part of PEP 3156. It is solid and I don't see any reason why it should get a reprieve from the usual strict backwards compatibility standards.
One part which can be improved is that right now the selectors module doesn't take advance of e/poll()'s modify() method: instead it just unregister() and register() the fd every time, which is of course considerably slower (there's also a TODO in the code about this). I guess that can be fixed later in a safely manner.
Another concern I have is that we should probably rename self._epoll, self._select, self._kqueue to just "self._poller": that would make subclassing easier (see patch in issue http://bugs.python.org/issue18931) and would provide a unified interface for those users who want to reference the underlying poller object for some reason.
Those are currently private APIs regardless, so provisional or stable doesn't make a difference to our ability to change them. Provisional status is designed to cover cases like asyncio or the 3.3 ipaddress module, where we think they're largely ready for inclusion in the standard library, but aren't yet prepared to offer full backwards compatibility guarantees due to the potential discovery of issues in some of the more obscure edge cases. It's still preferred to skip that step if the contributors/maintainers of a new module are confident in the level of vetting the API has already received (the smaller and more targeted the API, the easier it is to skip an initial provisional release, especially when incorporating an existing PyPI project that doesn't require any significant API changes to be suitable for the stdlib). The experience with ipaddress (where we flipped it to stable for 3.4 with only changes that could be counted as bug fixes anyway) is still the one we expect to be typical for provisional modules. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia