Maybe asyncio should just be kept provisional during 3.5, with a separate promise to remain backward compatible?
On Thu, Aug 27, 2015 at 3:24 PM, Yury Selivanov <yselivanov...@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 > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
