[Python-Dev] provisional status for asyncio

[Nick Coghlan]

On 29 August 2015 at 04:44, Gustavo Carneiro <gjcarneiro at gmail.com> wrote:
> On 28 August 2015 at 17:11, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
>>
>> On 2015-08-28 11:44 AM, Brett Cannon wrote:
>>>
>>>
>>>     Unfortunately, separating it from the standard library is something
>>>     that I don't think we can do so late in the 3.5 release candidates
>>>     process.
>>>
>>>
>>> Ultimately it's Larry's call, but I don't see why we couldn't. If we were
>>> talking about something as low-level as the urllib package then I would
>>> agree, but beyond its own tests is there anything in the stdlib that depends
>>> on asyncio?
>>
>>
>> As Victor already replied, asyncio is pretty self contained, and
>> nothing in the stdlib depends on it.
>>
>> If we really can remove it, let's consider it.
>
> -1 for removing it.  It is way too late for 3.5 IMHO.  You should have
> proposed it at least 6 months ago.  This feels too rushed.
>
> +1 for changing sys.path to allow pip-installed asyncio to override the
> stdlib version (for 3.6).  Some developers complain that NodeJS's packaging
> system is better that Python, maybe this lack of flexibility is one of the
> reasons...

I think ensurepip now offers us a better option for dealing with this
kind of situation: create a new category of "recommended" 3rd party
modules, which have their own upgrade cycle and maintenance model,
independent of the standard library, but use pip and bundled wheel
files to install them by default in the CPython installers. This
allows them to be made available by default to new Python users, but
also still easily kept in sync across all supported Python versions.

We've started inching our way towards this already, with provisional
modules, the IDLE enhancement exception for all releases, the network
security backports to Python 2.7, and ensurepip itself.

This means it isn't just asyncio that could benefit from such an
enhancement to our modularisation capabilities - we could also apply
it to tkinter, idle and distutils (all of which are often unbundled by
downstream redistributors anyway), and potentially even to
particularly security sensitive components like the ssl module.

>From a Linux downstream perspective, APT has long supported a
distinction between hard requirements, recommended additions, and
suggested ones in the Debian world, and RPM recently gained that
capability as well, so such a change would actually make our lives
easier, since "bundled as a wheel file" in the CPython Windows and Mac
OS X installers would map to a Recommends or Suggests downstream,
rather than a hard requirement.

However, we don't need to rush into this. As long as we keep asyncio
provisional for 3.5.0, then we can take our time in considering what
we want to do in terms of its ongoing maintenance and release
management model, and then apply that new approach to at least asyncio
for 3.5.x, and consider modularising the development and release
cycles for other components of interest in 3.6+ (and potentially 2.7.x
in some cases).

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia