[Python-Dev] provisional status for asyncio

[Brett Cannon]

On Thu, 27 Aug 2015 at 15:44 Guido van Rossum <guido at 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 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/20acfcd6/attachment.html>