On 28 August 2015 at 09:00, Yury Selivanov <yselivanov.ml@gmail.com> wrote:
Brett,
On 2015-08-27 6:46 PM, Brett Cannon wrote: [...]
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.
I'm fine with keeping it provisional in 3.5 (and Guido suggests this idea too in this thread).
A lot of companies (including big ones) are using asyncio already, despite the fact that it's provisional in 3.4. I seriously doubt that keeping it provisional in 3.5 will do any harm.
asyncio documentation in 3.4.x has the following notes section:
Note: The asyncio package has been included in the standard library on a provisional basis. Backwards incompatible changes (up to and including removal of the module) may occur if deemed necessary by the core developers.
I suggest to add a slightly less strong-worded note to 3.5 documentation:
Note: The asyncio package has been included in the standard library on a provisional basis. Backwards incompatible changes may occur if deemed absolutely necessary by the core developers.
I'd suggest including a clearer motivation there: Note: The asyncio package has been included in the standard library on a provisional basis, and thus may gain new APIs and capabilities in maintenance releases as it matures. Backwards incompatible changes may occur if deemed absolutely necessary by the core developers. It's a gentler phrasing that still serves to warn away folks that are particularly change averse, while also assuring folks on faster iteration cycles that the update cadence is still 6 months rather than 18-24 months. New standard library APIs could thus evolve through "not stable yet" -> "mostly stable" -> "stable". This is essentially Yury's original "two levels of provisional" idea - if a package survives an entire release cycle, it's pretty clear we're not going to be taking it out, but it's also the case that a comparatively broad API like asyncio may take a couple of feature release cycles to settle down to a point where we can declare it sufficiently complete that we're only going to add new interfaces in future feature releases. asyncio's just the first addition we've made under the PEP 411 guidelines that's big enough to benefit from the extra release cycle of stabilisation. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia