Skip to content
This repository has been archived by the owner. It is now read-only.

Add a _closed attribute to BaseEventLoop #169

Closed
GoogleCodeExporter opened this issue Apr 10, 2015 · 6 comments
Closed

Add a _closed attribute to BaseEventLoop #169

GoogleCodeExporter opened this issue Apr 10, 2015 · 6 comments

Comments

@GoogleCodeExporter
Copy link

@GoogleCodeExporter GoogleCodeExporter commented Apr 10, 2015

Some users try to use an event loop after it was closed:
http://bugs.python.org/issue21326

I propose to add a _closed attribute to the BaseEventLoop and use it to raise a 
exception with an explicit messsage (the event loop is closed). The patch 
changes run_forever() and run_until_complete() methods. It adds also a 
__repr__() method which contains this closed state, but also running and debug 
flags.

Patch:
https://codereview.appspot.com/98680044

Original issue reported on code.google.com by victor.s...@gmail.com on 28 May 2014 at 10:56

@GoogleCodeExporter
Copy link
Author

@GoogleCodeExporter GoogleCodeExporter commented Apr 10, 2015

Maybe "_active" would be a better name?

Original comment by yseliva...@gmail.com on 28 May 2014 at 11:08

@GoogleCodeExporter
Copy link
Author

@GoogleCodeExporter GoogleCodeExporter commented Apr 10, 2015

I don't understand the name "active". We have already an _running attribute 
(True when the loop is executing run_forever, False otherwise). _closed is 
different of _running, it's set to True at the first call to close().

I prefer the name "_closed". The io module exposes a read-only "closed" 
property for file objects. Internally, it uses a "__closed" flag and raises 
exception if the file was closed. My idea comes from there.

Original comment by victor.s...@gmail.com on 28 May 2014 at 11:11

@GoogleCodeExporter
Copy link
Author

@GoogleCodeExporter GoogleCodeExporter commented Apr 10, 2015

I'm with Victor on the terminology. Maybe we need to expose the closed flag.

Original comment by gvanrossum@gmail.com on 28 May 2014 at 11:36

@GoogleCodeExporter
Copy link
Author

@GoogleCodeExporter GoogleCodeExporter commented Apr 10, 2015

I updated my patch to add a new BaseEventLoop.is_closed() method, instead of 
using a private BaseEventLoop._closed attribute.
https://codereview.appspot.com/98680044

I'm not sure that I addressed all comments.

Original comment by victor.s...@gmail.com on 2 Jun 2014 at 9:27

@GoogleCodeExporter
Copy link
Author

@GoogleCodeExporter GoogleCodeExporter commented Apr 10, 2015

I pushed my change into Tulip (6c664ea639c6) and Python 3.5 (690b6ddeee9c): add 
a new is_closed() method to event loops.

For the BaseEventLoop.__repr__() method, Yury proposed to just return 
"<BaseEventLoop closed>" instead "<BaseEventLoop running=... debug=... 
closed=True>". I opened the issue #171, because it is possible to stop an event 
loop while it is running. Yury's suggestion would loose information, but 
closing a running event loop also looks like a bug. Let's discuss that in the 
issue #171.

Thanks for the useful review Guido and Yury.

I didn't push my changes to Python 3.4 because we don't add new methods in 
minor Python releases (Python 3.4.2).

Original comment by victor.s...@gmail.com on 3 Jun 2014 at 11:11

  • Changed state: Fixed
@GoogleCodeExporter
Copy link
Author

@GoogleCodeExporter GoogleCodeExporter commented Apr 10, 2015

Actually for asyncio we have special dispensation to push new features to minor 
releases (until 3.5). Please push to 3.4 so the source code is the same 
everywhere (except selectors.py, which is not covered by the exception).

Original comment by gvanrossum@gmail.com on 3 Jun 2014 at 11:15

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant