On 11/01/2011 06:48 PM, Glyph wrote: > Nevertheless, "real reactor as default argument" is not a huge > improvement either, because it typically breaks one level out. If > you have 'a(reactor=defaultReactor)' and then 'b()' needs to call > 'a', half the time 'b' will forget to supply a reactor argument and > call 'a()' passing nothing, because that appears to be the suggested
Darn. I hadn't thought of that. You could always walk back up the call stack looking for the implemenation of IReactorXXX that you want... what? Stop looking at me like that! I kid of course... the right answer is to make everything a method on the reactor! No wait... > So despite its imperfections, I don't have a solution better than > "pass the reactor to everything" yet. It seems to be better than the > alternatives in almost every case. The one place it's not better is > when writing brief example scripts, but I suspect this is only the Well, not only brief example scripts; brief actual scripts. One of the nice things about Twisted is that, with a bit of familiarity, you can knock up some really fast & powerful event-based network clients for ad-hoc jobs. One example, we use a tiny script wrapping DeferredSemaphore and t.p.utils.getProcessOutput to parallelise SSH scanning, because ssh-keyscan is (ahem) poorly implemented. Maybe I knock up more of these short 20-liners than is common? And typing "reactor, " a lot in them seems a bit, well... retrograde. But you're right. Default "reactor=X" parameters will just get passed wrong, dammit... > If you can think of a better solution that addresses all of these > concerns simultaneously somehow, please share, I'd love to hear it > :-). Hmpf. I suspect you've covered most of the ground. If anything springs to mind I'll be sure to speak up! Cheers, Phil _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
