<div dir="ltr">Maybe asyncio should just be kept provisional during 3.5, with a separate promise to remain backward compatible?<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 27, 2015 at 3:24 PM, Yury Selivanov <span dir="ltr"><<a href="mailto:yselivanov.ml@gmail.com" target="_blank">yselivanov.ml@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2015-08-27 5:53 PM, Brett Cannon wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Considering that Python versioning is defined as<br>
major.minor.micro, I'll<br>
rephrase the proposal:<br>
<br>
Level 1: Backwards incompatible changes might be introduced in new<br>
Python releases (including micro releases)<br>
<br>
Level 2: Only backwards compatible changes (new APIs including) can be<br>
introduced in micro releases.<br>
<br>
<br>
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.<br>
</blockquote>
<br></span>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
I should also mention that asyncio is different from other packages in the stdlib:<br>
<br>
1. It's new, it virtually didn't exist before 3.4.0.<br>
<br>
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?<br>
<br>
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.<div class="HOEnZb"><div class="h5"><br>
<br>
Yury<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/guido%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/guido%40python.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>