Ok, I've now submitted it. Stacklesslib.async has been revamped a bit. It is now basically a module to support the "async" decorator and calling convention. It relies on stacklesslib.futures for the future support. "Task" has been removed, we now use the "future" nomenclature. Still experimental, I want to see if this is a useful paradigm borrowing from C#
> -----Original Message----- > From: [email protected] [mailto:stackless- > [email protected]] On Behalf Of Kristján Valur Jónsson > Sent: 25. september 2013 09:58 > To: The Stackless Python Mailing List > Subject: Re: [Stackless] stacklesslib.async > > > > > -----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 _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
