Re: [Twisted-Python] why can't a callback be called with a deferred?
![](https://secure.gravatar.com/avatar/e1554622707bedd9202884900430b838.jpg?s=120&d=mm&r=g)
I just can't parse this sentence. Breaking it down:
you have no reference to the object being calls,
How do you have no reference to the object being called? Aren't you calling it?
or sometimes a result that's a deferred you need to wait on, particularly in a test, but have no way of doing so
But... you do have a way of doing so. You yield it from inlineCallbacks or you add a callback to it. In any case you either have a Deferred or you don't; if you do, then it's clear you should wait on it, if you don't, then it's clear you should not wait on it. If you want an API that allows some user code to do either, that's what 'maybeDeferred' is for.
Some type annotations might make it a bit clearer what the two states here are :). As it is, it looks to me you want a Deferred to come *out* of a 'yield', which should definitely never happen. If this assert were to be removed, it would be done in such a way that would implicitly wait for the Deferred in question to fire: you should never receive a Deferred as an argument to a function, or as the result of an (inlineCallbacks) 'yield' or (async def) 'await'. It breaks the whole model of what 'awaiting' means. -g
![](https://secure.gravatar.com/avatar/599519579a707ab348b35cf68477df08.jpg?s=120&d=mm&r=g)
On 21/02/2019 07:32, Glyph wrote:
Sorry, some typos in there are not helping ;-(
That test case I linked to shows one example, the original ones were from abstracting out JML's original post here: https://jml.io/pages/how-to-disconnect-in-twisted-really.html
In any case you either have a Deferred or you don't; if you do, then it's clear you should wait on it,
Yes, but where to wait is the question here. I'd like to leave that choice to the user (see back in the thread for the details).
If those annotations were there, what would they look like? (I did link to the whole test file, which has all the detail I think you could need, it's pretty self contained and not that long)
As it is, it looks to me you want a Deferred to come *out* of a 'yield', which should definitely never happen.
I disagree, in this specific case.
Well, I'd agree 90% of the time, but test_untracked_deferred.py is where that's no always true. Anyway, I'm happy with the API I have now, and it neatly works around that assert, so ¯\_(ツ)_/¯. Chris
![](https://secure.gravatar.com/avatar/599519579a707ab348b35cf68477df08.jpg?s=120&d=mm&r=g)
On 21/02/2019 07:32, Glyph wrote:
Sorry, some typos in there are not helping ;-(
That test case I linked to shows one example, the original ones were from abstracting out JML's original post here: https://jml.io/pages/how-to-disconnect-in-twisted-really.html
In any case you either have a Deferred or you don't; if you do, then it's clear you should wait on it,
Yes, but where to wait is the question here. I'd like to leave that choice to the user (see back in the thread for the details).
If those annotations were there, what would they look like? (I did link to the whole test file, which has all the detail I think you could need, it's pretty self contained and not that long)
As it is, it looks to me you want a Deferred to come *out* of a 'yield', which should definitely never happen.
I disagree, in this specific case.
Well, I'd agree 90% of the time, but test_untracked_deferred.py is where that's no always true. Anyway, I'm happy with the API I have now, and it neatly works around that assert, so ¯\_(ツ)_/¯. Chris
participants (2)
-
Chris Withers
-
Glyph