> -----Original Message----- > From: [email protected] [mailto:stackless- > [email protected]] On Behalf Of Richard Tew > Sent: 25. september 2013 08:26 > To: The Stackless Python Mailing List > Subject: Re: [Stackless] stacklesslib.async > > Other than that, there's a sense that you should merge in the 3.3 futures > support into the Stackless 2.7+ and stacklesslib should be monkeypatching it.
I'm not sure I understand what you mean, do you mean the regular 3.3. futures? The stacklesslib.futures are deliberately stackless-like as they use channels and such features for switching. I don't think it is easy, or desirable, to may them interoperable with 'regular' futures that use condition variables and such. It _could_ be made possible by monkeypatching condition variables, but then we have the multiprocessing stuff... In other words, it is not possible to use concurrent.futures.wait with stacklesslib.futures, and vice versa. So the prime idea here was to create an api that would be familiar top people, without promising full compatibility with actual modules. I must still admit that I find the futures api a bit awkward. Particulary the use of an enum for futures.wait() is very un-pythoninc. The lack of "attributes" on futures. And the executor.map() being the only way to launch futures in parallel is akward. We aim to put this to practical use with stackless in-house and we'll see what real-world use cases come out of that :) K _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
