• Jean-Paul Calderone [2025-01-10 16:56]:
On Fri, Jan 10, 2025 at 10:39 AM Kirill Miazine <k...@krot.org
<mailto:k...@krot.org>> wrote:
I'm playing with PB, and it's booth cool and somewhat confusing. So I
have some remote_* methods, e.g.
def remote_ping(self):
return 'pong'
def remote_run(self):
d = Deferred()
d.AddCallback(self.got_result)
# return d # <- magic here when deferred is returned?
def got_result(self, res)
return res
When I do callRemote('ping') and execute callback, I am getting 'pong'
as a result. However, when I do callRemote('run'), it returns a
deferred which returns None, which is expected, as remote_run()
doesn't have any result yet.
However, if I return deferred ("d") from remote_run, then
callRemote('run') gives me
the result. Is it some expected magic going on when remote_ method
returns a deferred?
First, while PB probably is objectively pretty cool, you almost
certainly shouldn't use it. The complexity isn't warranted except
perhaps for a very few specific kinds of applications. Even for those
applications, the level of development on PB means that many features
you will likely want aren't available and even those features which are
available have implementation shortcomings that aren't likely to be
addressed. /IMO/ the entire package should have been split out of
Twisted long ago.
Ouch. Tanks for the warning. Are there other parts of Twisted which
should be avoided for new stuff?
As implied by the above, the right choice of protocol for your
application does depend on your application's specific requirements.
That said, HTTP is a pretty good fit for a wide range of common
application types.
I came from HTTP. In fact, the PB remote_run receives some pickled data
and HMAC digest, and the response is constructed in a similar way. So PB
is just a way to avoid HTTP.
Another protocol Twisted supports, AMP, covers some
more ground - though you might find wider support for similar protocols
such as those based on ProtoBufs or msgpack (AMP is a Twisted invention
and though it has a number of very nice properties, you won't find many
people using it).
Thanks for the AMP pointer, it seems more modern. I'll give it a try.
To answer the question you asked, there is a limited amount of magic
going on that allows you to return a Deferred and have the method behave
as though it returned the result that Deferred eventually fires with,
instead. This is a common pattern when developing with Twisted as it
makes dealing with asynchronous implementations more convenient. In
fact, it's essentially the reason Deferred exists at all.
Yes, it felt very logical, but I didn't find it mentioned in the docs,
thus a need for a confirmation.
You'll find this feature in Twisted's implementation of AMP and HTTP and
many other protocols as well.
I love it!
Jean-Paul
_______________________________________________
Twisted mailing list -- twisted@python.org
To unsubscribe send an email to twisted-le...@python.org
https://mail.python.org/mailman3/lists/twisted.python.org/
Message archived at
https://mail.python.org/archives/list/twisted@python.org/message/OCSYNCH5AXRT5J43QD3QO3RDJX43YNDZ/
Code of Conduct: https://twisted.org/conduct
_______________________________________________
Twisted mailing list -- twisted@python.org
To unsubscribe send an email to twisted-le...@python.org
https://mail.python.org/mailman3/lists/twisted.python.org/
Message archived at
https://mail.python.org/archives/list/twisted@python.org/message/DF2FNROSJAGT3BGGBF7P3YLHDEPLK36U/
Code of Conduct: https://twisted.org/conduct
