[Python-Dev] Confirming status of new modules in 3.4

[Nick Coghlan]

On 15 March 2014 21:02, Giampaolo Rodola' <g.rodola at gmail.com> wrote:
>
> On Sat, Mar 15, 2014 at 3:17 AM, Guido van Rossum <guido at 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 at gmail.com   |   Brisbane, Australia