[Python-Dev] provisional status for asyncio

[Gustavo Carneiro]

I think this is a packaging problem.

In an ideal world, Python would ship some version of asyncio, but you would
also be able to pip install a newer version into your virtual environment,
and it would override the version in stdlib.

As it stands now, however, if you pip install another version of asyncio,
the version in stdlib still takes precedence.  What I end up doing in my
(non open source) projects is to include a copy of asyncio and manually
modify sys.path to point to it.

Can we fix pip/virtualenv instead?
On 28 Aug 2015 10:02 am, "Victor Stinner" <victor.stinner at gmail.com> wrote:

> Hi,
>
> 2015-08-27 23:15 GMT+02:00 Yury Selivanov <yselivanov.ml at gmail.com>:
> > Recently, in an asyncio related issue [1], Guido said that new features
> > for asyncio have to wait till 3.6, since asyncio is no longer a
> provisional
> > package. (...)
> > For example, there is an issue [2] to add starttls support to asyncio.
> > (...)
> > Aside from adding new APIs, we also have to improve debugging
> > capabilities.
> > (...)
>
> I would propose something more radical: remove asyncio from the stdlib.
>
> PEP 411: "While it is considered an unlikely outcome, such packages
> *may even be removed* from the standard library without a deprecation
> period if the concerns regarding their API or maintenance prove
> well-founded."
>
> As an asyncio developer, I'm not sure that asyncio fits well into the
> Python stdlib. The release cycle of feature release is long (18
> months? or more?), the release cycle for bugfix release is sometimes
> also too long (1 month at least). It's also frustrating to have subtle
> API differences between Python 3.3, 3.4 and 3.5. For example,
> asyncio.JoinableQueue was removed in Python 3.5, asyncio.Queue can
> *now* be used instead, but asyncio.JoinableQueue should be used on
> older Python version... It means that you have to write different code
> depending on your Python version to support all Python versions.
>
> I can give much more examples of missing asyncio features. Example:
> Windows proactor event loop doesn't support signals (CTRL+C) nor UDP.
>
> asyncio is moving so fast, that changes are not documented at all in
> Misc/NEWS or Doc/whatsnews/x.y.rst. I tried to document changes in my
> fork Trollius. See its changelog to have an idea how fast asyncio is
> still changing:
> http://trollius.readthedocs.org/changelog.html
>
> I don't know how users will react to the removal of asyncio from the
> stdlib ("asyncio is not trusted/supported by Python?").
>
> The idea is to install it using pip: "pip install asyncio". The major
> difference is that "pip install -U asyncio" allows to retrieve the
> latest asyncio version, independently of your Python version. Hum, I
> don't know if it works with Python 3.4 (which "asyncio" module is used
> in this case?).
>
> Developing asyncio only on Github would avoid the risk of having
> patches temporary only in Github or only in CPython. It avoids the
> need to synchronize the Git (Github) and Mercurial (CPython)
> repositories.
>
>
> Compare Python release dates with Twisted, Tornado and eventlet release
> dates.
>
> Twisted releases:
>
> * 2015-01-30: 15.0.0
> * 2015-04-13: 15.1.0
> * 2015-05-19: 15.2.0
> * 2015-08-04: 15.3.0
>
> Tornado releases:
>
> * 2014-07-15: 4.0
> * 2015-02-07: 4.1
> * 2015-05-27: 4.2
> * 2015-07-17: 4.2.1
>
> eventlet releases:
>
> * 2015-02-25: 0.17.1
> * 2015-04-03: 0.17.2
> * 2015-04-09: 0.17.3
> * 2015-05-08: 0.17.4
>
> Victor
> _______________________________________________
> 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/gjcarneiro%40gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150828/8d85574f/attachment-0001.html>