[Twisted-Python] inlineCallbacks as a blocking approximator (stylistic)
First off, I've read [1] and am not trying to convert twisted code into blocking code (well, I WAS, but have reconsidered). I've got Kivy code using twisted code without much problem, but really hated defining many in-line functions/lambdas for simple 'assign the result to a Kivy widget' style things. I'm now abstracting twisted-related code into its own class (separate from kivy UI code). My eventual aim is for Kivy-related code to be approximately:- val = doSomeCallRemoteCallHere(args) myWidget.text = val The closest I'm able to come to that so far is for my function to be decorated with @defer.inlineCallbacks which will then look like this val = yield doSomeCallRemoteCallHere(args) myWidget.text = val Much better readability than my previous def put_val_in_widget(retval): myWidget.text = retval d = doSomeCallRemoteCallHere(args) d.addCallback(put_val_in_widget) Is this as 'good' (for the subjective readability concern) as it gets? I'm basically going for sufficient readability that my UI code can be read by programmers stuck in a synchronous mindset. [1] - http://glyf.livejournal.com/40037.html
Oon-Ee Ng <ngoonee.talk@gmail.com> writes:
You can even do "myWidget.text = yield somethingDeferred()"
Is this as 'good' (for the subjective readability concern) as it gets?
Yes. Unless you move everything to Python 3 and then you can use the async / await syntax (with Twisted), which is more-or-less the same as the above (but you avoid the decorator). It would look like: myWidget.text = await somethingDeferred() -- meejah
On Tue, Oct 4, 2016 at 12:42 PM, meejah <meejah@meejah.ca> wrote:
Why yes, that makes sense.
I would if I could, most of my projects are already there but last I checked (beginning of the year) the _threadedselect reactor wasn't fully ready yet, and AMP wasn't ported. I see a lot of progress on that front with Amber's frequent updates here, so will migrate when I can, but in the meantime I'm keeping things on python2 (no official release of the app yet, so its not a big deal to shift when ready).
On Mon, Oct 3, 2016 at 8:55 PM, Oon-Ee Ng <ngoonee.talk@gmail.com> wrote: like/understand Deferred. The `yield` based statement really helped me initially but more importantly over time I liked seeing an explicit difference between blocking vs non-blocking code. When I see `a = yield func()`, I immediately register the fact that this is a time-consuming operation which helps in understanding the performance of the system. So, yes it is a good start for synchronous mindset people.
On Tue, Oct 4, 2016 at 1:03 PM, Manish Tomar <manish.tomar@gmail.com> wrote:
Actually I really like the idea behind deferred, its just not the easiest to read and understand for others, and I don't want to be the only one maintaining my code. That being said 'yield=time-consuming' doesn't make sense to me. I'm using twisted (and AMP) for communication, not to offload processing, and some of the operations would be near-instant in a threaded context (obviously with the reactor running it has to wait till it gets picked up).
Oon-Ee Ng <ngoonee.talk@gmail.com> writes:
You can even do "myWidget.text = yield somethingDeferred()"
Is this as 'good' (for the subjective readability concern) as it gets?
Yes. Unless you move everything to Python 3 and then you can use the async / await syntax (with Twisted), which is more-or-less the same as the above (but you avoid the decorator). It would look like: myWidget.text = await somethingDeferred() -- meejah
On Tue, Oct 4, 2016 at 12:42 PM, meejah <meejah@meejah.ca> wrote:
Why yes, that makes sense.
I would if I could, most of my projects are already there but last I checked (beginning of the year) the _threadedselect reactor wasn't fully ready yet, and AMP wasn't ported. I see a lot of progress on that front with Amber's frequent updates here, so will migrate when I can, but in the meantime I'm keeping things on python2 (no official release of the app yet, so its not a big deal to shift when ready).
On Mon, Oct 3, 2016 at 8:55 PM, Oon-Ee Ng <ngoonee.talk@gmail.com> wrote: like/understand Deferred. The `yield` based statement really helped me initially but more importantly over time I liked seeing an explicit difference between blocking vs non-blocking code. When I see `a = yield func()`, I immediately register the fact that this is a time-consuming operation which helps in understanding the performance of the system. So, yes it is a good start for synchronous mindset people.
On Tue, Oct 4, 2016 at 1:03 PM, Manish Tomar <manish.tomar@gmail.com> wrote:
Actually I really like the idea behind deferred, its just not the easiest to read and understand for others, and I don't want to be the only one maintaining my code. That being said 'yield=time-consuming' doesn't make sense to me. I'm using twisted (and AMP) for communication, not to offload processing, and some of the operations would be near-instant in a threaded context (obviously with the reactor running it has to wait till it gets picked up).
participants (3)
-
Manish Tomar -
meejah -
Oon-Ee Ng