[Python-Dev] provisional status for asyncio

[Nick Coghlan]

On 28 August 2015 at 09:00, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
> Brett,
>
> On 2015-08-27 6:46 PM, Brett Cannon wrote:
> [...]
>>
>> I say it's either fully provisional or it's not. I'm fine with extending
>> its provisional status another feature release as long as it clearly states
>> that in What's New for 3.5, but I don't think this granularity guarantee of
>> not breaking APIs while adding new features is worth it. What if you want to
>> add a new feature that is really hard to do right without breaking
>> compatibility? We all know how trying that is. If you truly want to keep an
>> accelerated development cycle, then short of releasing new stdlib versions
>> every 6 months separate from the language then I say keep it provisional for
>> 3.5.
>
>
> I'm fine with keeping it provisional in 3.5 (and Guido suggests this idea
> too in this thread).
>
> A lot of companies (including big ones) are using asyncio already, despite
> the fact that it's provisional in 3.4.  I seriously doubt that keeping it
> provisional in 3.5 will do any harm.
>
> asyncio documentation in 3.4.x has the following notes section:
>
>     Note: The asyncio package has been included in the
>     standard library on a provisional basis. Backwards
>     incompatible changes (up to and including removal
>     of the module) may occur if deemed necessary by the
>     core developers.
>
> I suggest to add a slightly less strong-worded note to 3.5 documentation:
>
>     Note: The asyncio package has been included in the
>     standard library on a provisional basis. Backwards
>     incompatible changes may occur if deemed absolutely
>     necessary by the core developers.

I'd suggest including a clearer motivation there:

    Note: The asyncio package has been included in the standard
library on a provisional basis, and thus may gain new APIs and
capabilities in maintenance releases as it matures. Backwards
incompatible changes may occur if deemed absolutely necessary by the
core developers.

It's a gentler phrasing that still serves to warn away folks that are
particularly change averse, while also assuring folks on faster
iteration cycles that the update cadence is still 6 months rather than
18-24 months. New standard library APIs could thus evolve through "not
stable yet" -> "mostly stable" -> "stable".

This is essentially Yury's original "two levels of provisional" idea -
if a package survives an entire release cycle, it's pretty clear we're
not going to be taking it out, but it's also the case that a
comparatively broad API like asyncio may take a couple of feature
release cycles to settle down to a point where we can declare it
sufficiently complete that we're only going to add new interfaces in
future feature releases.

asyncio's just the first addition we've made under the PEP 411
guidelines that's big enough to benefit from the extra release cycle
of stabilisation.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia