On Thu, 27 Aug 2015 at 15:44 Guido van Rossum <guido@python.org> wrote:
Maybe asyncio should just be kept provisional during 3.5, with a separate promise to remain backward compatible?

My worry is that promising backwards-compatibility while still trying to change things is going to lead to needlessly hampering the evolution of the framework. If you want to say you will try hard to not break code and stay provisional I'm all for that (although I assume we already do that anyway), but making our standard backwards-compatibility promise on top of new features just seems too messy to me without knowing where the new features will take you. Past that it seems like asyncio is cheating on our bugfix release compatibility promises because it was lucky enough to be added as provisional.

I realize asyncio went in like it did partially to motivate `yield from` and now async/await, and that's fine. But I say go all-in and just stay provisional another release and then lock it down in 3.6.

-Brett
 

On Thu, Aug 27, 2015 at 3:24 PM, Yury Selivanov <yselivanov.ml@gmail.com> wrote:
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

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev



--
--Guido van Rossum (python.org/~guido)