On 24 May 2010 03:58, Cameron Simpson <cs at zip.com.au> wrote: > I almost am Brian's hypothetical user. I've got a "FuncMultiQueue" that > accepts callables in synchronous and asynchronous modes for future > possibly-concurrent execution, just as the futures module does. I've > spent a _lot_ of time debugging it. I pretty much am that user as well (whether or not I am hypothetical, I'll leave to others to determine...) I have a set of scripts that needed to do precisely the sort of thing that the futures module offers. I searched for a fair while for a suitable offering (this was before futures had been published) and found nothing suitable. So in the end I implemented my own - and I hit corner cases, and they needed a lot of work to fix. I now have a working solution, but it's too tangled in the application logic to be reusable :-( If futures had been in the stdlib, I'd have used it like a shot, and saved myself a lot of wasted time. > There's a lot to be said for a robust implementation of a well defined > problem. Brian's module, had it been present and presuming it robust and > debugged, would have been quite welcome. Precisely my view. Paul.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4