[Python-Dev] provisional status for asyncio
brett at python.org
Fri Aug 28 17:44:07 CEST 2015
On Fri, 28 Aug 2015 at 08:35 Yury Selivanov <yselivanov.ml at gmail.com> wrote:
> On 2015-08-28 5:01 AM, Victor Stinner wrote:
> > Hi,
> > 2015-08-27 23:15 GMT+02:00 Yury Selivanov <yselivanov.ml at gmail.com>:
> >> Recently, in an asyncio related issue , Guido said that new features
> >> for asyncio have to wait till 3.6, since asyncio is no longer a
> >> package. (...)
> >> For example, there is an issue  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.
> I too would enjoy more frequent release schedule of asyncio.
> 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
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?
> > 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?").
> That's another concern.
> > 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?).
> The one from the stdlib.
> > 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
> > 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
> These are very good stats. It shows that even mature async libraries
> require frequent release cycles.
> Anyways, I vote for at least keeping asyncio provisional in 3.5.x.
> I'd be glad if we can consider to have more bugfix releases of 3.5
> (and 3.6), say every 3 months.
> Python-Dev mailing list
> Python-Dev at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev