3 ms·
I only have around ~1 year of twisted experience, but I felt like the viral aspect of twisted was even worse than that. Not only everything needs to be asynchr
by cdavid 13y ago
I only have around ~1 year of twisted experience, but I felt like the viral aspect of twisted was even worse than that.
Not only everything needs to be asynchronous, but using deferred leaks everywhere in your API. Deferred callback firing mechanism 'recursively' passing the result of the previous callback is the most egregious aspect of it. Yet, I think deferred is by far the most readable/maintanable method to write async in twisted. For example, inlineCallbacks looks nice on paper, until you start using them and realize stacktraces are often wrong, and that you loose a lot of concurrency by forcing things that could run in // to be serialized.
I think explicit async is simply the wrong model for a dynamic language. Often, async is just an optimization, and more efforts should be spent on how to make it happen under the hood.
- rdtsc 13y ago> but using deferred leaks everywhere in your API Exactly. To expand on it. Glyph and/or Guido, I have heard say how the fact that IO is happening is very important and one should an obvious explicit callback in the algorithm. (Those using yield based concurrency also agree but just say to stick a yield in there instead of a deferred+callback). I disagree. If one particular API function happens to use Twisted shouldn't affect the user or caller of the functions. Using a particular IO library should be an implementation detail.