-
-
Notifications
You must be signed in to change notification settings - Fork 32.3k
bpo-33238: Add InvalidStateError to concurrent.futures. #7056
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Future.set_result and Future.set_exception now raise InvalidStateError if the futures are not pending or running. This mirrors the behavior of asyncio.Future, and prevents AssertionErrors in asyncio.wrap_future when set_result is called multiple times.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
Please add a NEWS entry and update the docs.
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
Lib/concurrent/futures/_base.py
Outdated
@@ -513,6 +517,8 @@ def set_result(self, result): | |||
Should only be used by Executor implementations and unit tests. | |||
""" | |||
with self._condition: | |||
if self._state in [CANCELLED, CANCELLED_AND_NOTIFIED, FINISHED]: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use tuple instead of a list.
By this, the tuple is stored in code object.
List is recreated every time on the function execution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would normally use a tuple, but went with a list because that's the style the rest of the module used. Should I update the other methods in Future to use tuples?
Lib/concurrent/futures/_base.py
Outdated
@@ -526,6 +532,8 @@ def set_exception(self, exception): | |||
Should only be used by Executor implementations and unit tests. | |||
""" | |||
with self._condition: | |||
if self._state in [CANCELLED, CANCELLED_AND_NOTIFIED, FINISHED]: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
list -> tuple
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd actually use set here.
Lib/test/test_concurrent_futures.py
Outdated
f = create_future(state=PENDING) | ||
f.set_result(1) | ||
|
||
with self.assertRaises(futures.InvalidStateError): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use assertRaisesRegex
to make sure that error text fits expectation.
Lib/test/test_concurrent_futures.py
Outdated
e = ValueError() | ||
f.set_exception(e) | ||
|
||
with self.assertRaises(futures.InvalidStateError): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
assertRaisesRegex
I have made the requested changes; please review again |
@asvetlov The PR looks fine to me now. Could you please take another look? |
So will this end up in 3.7.0? I didn't plan for that to happen... but if so, at least the what's new entry must be added. @asvetlov |
@1st1, it's your call at the moment. Unless it is backported, it won't be in 3.7.0. If you really think it should be, please make it happen right away so we can get it in 3.7.0b5 which is planned to be tagged very soon. |
Well, it's a nice non-critical enhancement, so in my opinion it can wait till 3.8. By no means it should go to 3.7.1 and not to 3.7.0 though. |
Ah, this is in master branch only and there's no backport to 3.7, my bad, sorry for the noise. |
@jhaydaman Any reason you did not list |
Future.set_result and Future.set_exception now raise InvalidStateError
if the futures are not pending or running. This mirrors the behavior
of asyncio.Future, and prevents AssertionErrors in asyncio.wrap_future
when set_result is called multiple times.
https://bugs.python.org/issue33238