>>>>> "Glyph" == Glyph Lefkowitz <gl...@twistedmatrix.com> writes: Glyph> On Dec 8, 2009, at 11:09 PM, Terry Jones wrote: >> I just wrote a fun class that lets you >> >> - submit jobs to be dispatched to a queue >> - manage how many tasks are in progress at once >> - dynamically adjust that number >> - shut down cleanly, including >> - recovering jobs that were queued but hadn't been dispatched
Glyph> That does sound like fun! It *is* fun. >> # Later... send off some SMS messages. >> dispatcher.put((2127399921, 'Hello...')) >> dispatcher.put((5052929919, 'Test...')) Glyph> Not that this is really germane to the class in question, but, if Glyph> you're going to be sending SMS messages That was just an example. I even thought about using strings, but kept it looking simpler. >> # Later, bump up to 10 simultaneous jobs. >> dispatcher.width = 10 >> >> # Oops, turns out we're sending too fast, turn it down a little. >> dispatcher.narrow(3) Glyph> This seems somewhat asymmetric. Why are there 'widen' and 'narrow' Glyph> methods if I can just set the 'width' attribute directly? I could Glyph> always just do '.width +=' and '.width -=' if I have a relative Glyph> value. Agreed. I started out just implementing widen and narrow, and they (barely) survived when I later added the width property. I had been thinking it would be good to just be able to change the width up or down a notch, but then when I went to write my (a posteriori) tests, I realized that wasn't really so convenient. So I think you're right they could be simplified away. But the code Glyph, the code? Or have I graduated to the point where I no longer need a laconic garotting? I think the combo of a DeferredQueue and a task.Cooperator is pretty deadly. Terry _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
