[Python-Dev] provisional status for asyncio

[Yury Selivanov]

On 2015-08-27 5:53 PM, Brett Cannon wrote:
>
>
>     Considering that Python versioning is defined as
>     major.minor.micro, I'll
>     rephrase the proposal:
>
>     Level 1: Backwards incompatible changes might be introduced in new
>     Python releases (including micro releases)
>
>     Level 2: Only backwards compatible changes (new APIs including) can be
>     introduced in micro releases.
>
>
> In that case I don't think it's a good idea for something that has 
> widespread use to get new APIs in a micro release; I lived the 
> 2.2.1/boolean event and I don't want to go through that again. If a 
> module is used enough to warrant not breaking backwards-compatibility 
> then it warrants not being provisional and being like any other module.

I wasn't using Python 2.2/2.3, but from what I could google the 
"2.2.1/boolean event" you mention was introducing True/False/bool 
built-ins.  This sounds like a language-level change, as opposed to new 
API in a stdlib module, which is a different scale.

My understanding about adding new features in bugfix releases (3.5.x) is 
that you might end up in a situation where your 3.5 code developed on 
3.5.x suddenly stops working on 3.5.y.  Yes, you have to be careful 
about how you deploy and test your code when using a provisional package.

But the thing about asyncio is that it *is* still provisional in 3.4.  
During 3.4 release cycle we introduced many new features to asyncio, and 
to be honest, I haven't heard anybody complaining.  I believe that main 
motivation for making asyncio non-provisional was to guarantee that we 
won't introduce backwards-incompatible changes to it.

Given the fact that asyncio sees some adoption, I support that from now 
on we will guarantee that backwards compatibility is preserved. But 
withholding new useful (and sometimes essential) features till 3.6.0 is 
out (March 2017?) sounds wrong to me.

I should also mention that asyncio is different from other packages in 
the stdlib:

1. It's new, it virtually didn't exist before 3.4.0.

2. It's not a module, it's a framework.  If it lacks a core feature 
(like starttls) that is hard to implement as an add-on, you're basically 
forced either copy/paste a lot of code or to fork asyncio.  And if you 
fork it, how will your dependencies can be upgraded to use that fork?

I want to continue (as we did in 3.4.x releases) evolving asyncio on a 
faster scale than CPython currently evolves, *and* to guarantee that we 
won't break existing code.  That's why I propose to tweak our definition 
of provisional packages.

Yury