Victor,
On 2015-08-28 5:01 AM, Victor Stinner wrote:
Hi,
2015-08-27 23:15 GMT+02:00 Yury Selivanov <yselivanov...@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.
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
process.
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 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
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.
Yury
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
