> The bug comment seems to imply a more fundamental issue but if Twisted had such a fundamental bug it just wouldn't work. Exactly. It works just fine. > I th

> The bug comment seems to imply a more fundamental issue but if Twisted had such a fundamental bug it just wouldn't work. Exactly. It works just fine. > I think Guido's point is that you can still potentially add callbacks to a Deferred that has fired which opens an opportunity for bugs. He has a point there but you don't usually use Deferred that way. Generally when you add callbacks you know the Deferred hasn't fired yet. I still really don't see the problem with that. > I think Twisted isn't that bad but there are a few things I dislike about it: It's harder than I'm used to to combine synchronous and asynchronous. Twisted is "contagious". I'm hoping to demonstrate that that doesn't have to be true: see the end of this comment :) > Because the Twisted application "wants" to be single threaded, everything goes through the reactor and therefore everything has to be pure async. You can deviate from that but it has some amount of built in inflexibility. If I compare with C++ Boost::Asio there's much better multi-threading support in Asio with its worker threads (which is important for scaling across cores) and you can do more interesting combinations of async/sync IMO. > Twisted's @inlinecallbacks decorator allows you to write linear looking code you it also encourages a too-serialized way of doing things. The power of asynchronous is to do things in parallel but in Twisted you often either end up with very hard to follow "pure" asynch code or less efficient "chained" asynch code. At least that's my experience. Yes, I think that's definitely true :) @inlineCallbacks has its uses: if you really really want to do this bunch of things sequentially. Of course, since @inlineCallbacks decorated functions return deferreds, you can then use that with tools that let you manage a bunch of jobs in parallel. E.g. if a given task is a few steps, you can write it in an @inlineCallbacks decorated function, and then if you have to do a bunch of them, just call it a few times (and maybe pass the resulting deferreds to gatherResults if you want all of the results). I often end up with some code in @inlineCallbacks that wraps some regular callback code, or the other way around. They're different tools, and while on average my experience has given me an anti-inlineCallback bias, it has its uses :) > Related to combining async and sync styles you end up seeing things like isinstance(ret, Deferred). There's also maybedeferred for dealing with async vs. sync. Still not great. I'm really interested in this, because I'm writing a talk about mixing Twisted with other stuff. What about maybeDeferred do you take issue with? FWIW, I know of some shops, e.g. Vumi in South Africa, that mix sync and async just like this. I've made the repo[1] and preliminary slides[2] available :) [1]: https://github.com/lvh/TwistedMixing https://github.com/lvh/TwistedMixing [2]: http://blog.lvh.io/TwistedMixing http://blog.lvh.io/TwistedMixing