STINNER Victor added the comment:
The initial issue is now fixed, thanks for the report Mark Dickinson.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21326
Roundup Robot added the comment:
New changeset 7912179335cc by Victor Stinner in branch '3.4':
Issue #21326: Add a new is_closed() method to asyncio.BaseEventLoop
http://hg.python.org/cpython/rev/7912179335cc
--
___
Python tracker
STINNER Victor added the comment:
This issue was discussed on the python-dev mailing list. The conclusion is that
adding a new method to asyncio is safe because asyncio has a provisional API
(whereas the selectors module doesn't).
Ok, Python 3.4.2 will have the new method
Changes by Giampaolo Rodola' g.rod...@gmail.com:
--
components: +Asyncio
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21326
___
___
Guido van Rossum added the comment:
I don't want the 3.4 and 3.5 versions of asyncio to be different. You should
just copy the 3.5 code back into the 3.4 tree. A new method is fine. Really.
--
___
Python tracker rep...@bugs.python.org
Roundup Robot added the comment:
New changeset 690b6ddeee9c by Victor Stinner in branch 'default':
Issue #21326: Add asyncio.BaseEventLoop.is_closed() method
http://hg.python.org/cpython/rev/690b6ddeee9c
--
nosy: +python-dev
___
Python tracker
STINNER Victor added the comment:
I fixed the issue in Python 3.5 by adding a new BaseEventLoop.is_closed()
method. Calling run_forever() or run_until_complete() now raises an error.
I don't know yet if this issue should be fixed in Python 3.4. If it should be
fixed, I don't know how it
Changes by Yury Selivanov yselivanov...@gmail.com:
--
nosy: +yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21326
___
___
STINNER Victor added the comment:
Attached asyncio_closed_py34.patch: minimum patch to fix this issue.
run_forever() and run_until_complete() raises a RuntimeError if the event loop
was closed.
The patch only uses the private attribute BaseEventLoop._closed in the
BaseEventLoop class, not
STINNER Victor added the comment:
I proposed a patch upstream (in Tulip) to solve this issue:
http://code.google.com/p/tulip/issues/detail?id=169
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21326
New submission from Mark Dickinson:
In the new asyncio library, it's easy for newbies (like me) to accidentally try
to run a coroutine on a closed event loop. Doing so leads to a rather
inscrutable exception and traceback:
loop.run_until_complete(compute())
Traceback (most recent call
Guido van Rossum added the comment:
Hm, I've never hear from someone who did this before. It might be easy to fix,
but it would be ugly too (every EventLoop method would have to check this), and
not very useful (you'll only make this mistake once in your life).
How much time did you waste
Mark Dickinson added the comment:
Maybe we can just change repr(loop) to make it clear that it's closed?
That sounds good to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21326
___
Mark Dickinson added the comment:
How much time did you waste debugging this?
Not much: less than 5 minutes. While I *probably* won't make this mistake
again (though I'm not going to make any promises on that front), it would be
nice to prevent other people from doing so.
More info: I got
14 matches
Mail list logo
