[Python-Dev] provisional status for asyncio

[Guido van Rossum]

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.ml at 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 at 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150827/89b4478f/attachment.html>