[Python-Dev] provisional status for asyncio

[Brett Cannon]

On Thu, 27 Aug 2015 at 15:24 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.
>

True, but that doesn't mean that 3.5.1 will be able to run code that 3.5.0
has no chance of running because you introduced a new feature in asyncio.


>
> 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.
>

Right, but we're talking about 3.5 here, right?


> 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.
>

Sure, but now it does. You said yourself that asyncio is seeing adoption,
so exists now for at least some people.


>
> 2. It's not a module, it's a framework.


But it's still in the stdlib and has already gone through one release as
provisional.


>   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'm not forking so that's not my problem. =)


>
> 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.
>

I still don't like it. I say it's either fully provisional or it's not. I'm
fine with extending its provisional status another feature release as long
as it clearly states that in What's New for 3.5, but I don't think this
granularity guarantee of not breaking APIs while adding new features is
worth it. What if you want to add a new feature that is really hard to do
right without breaking compatibility? We all know how trying that is. If
you truly want to keep an accelerated development cycle, then short of
releasing new stdlib versions every 6 months separate from the language
then I say keep it provisional for 3.5.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150827/83739387/attachment-0001.html>