Skip to content
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

sessions.py: pep8 + put deferred as argument #2

Closed
wants to merge 2 commits into from

Conversation

yetanotherion
Copy link

This commit transfers the deferred used in request using an argument
of the function, instead of relying on the dynamic state of the scope
of the functions.

This commit transfers the deferred used in request using an argument
of the function, instead of relying on the dynamic state of the scope
of the functions.
@@ -73,5 +74,5 @@ def func():
reactor.callFromThread(d.errback, e)

d = defer.Deferred()
self.pool.callInThread(func)
self.pool.callInThread(func, d)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in this case, why only d, and not args/kwargs?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

because unlike d, args and kwargs are defined and thus included in the scope of f since its definition, not its execution. Without passing d explicitly, I'm not sure that the d used in f will, always, be the deferred defined l.75.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, I think this would deserve a proof. Either doc or unit test I
think we would experience much more problems if your theory is true...

In txrequests/sessions.py:

@@ -73,5 +74,5 @@ def func():
reactor.callFromThread(d.errback, e)

     d = defer.Deferred()
  •    self.pool.callInThread(func)
    
  •    self.pool.callInThread(func, d)
    

because unlike d, args and kwargs are defined and thus included in the
scope of f since its definition, not its execution. Without passing d
explicitly, I'm not sure that the d used in f will, always, be the deferred
defined l.75.


Reply to this email directly or view it on GitHub
https://github.com/tardyp/txrequests/pull/2/files#r18578177.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants