[Stackless] stacklesslib.async

[Kristján Valur Jónsson]

Hi there.
So, progress.  I have two pieces of news.  First:


I took many of your comments into account, Richard and have a new version of stackless.async in the repo:
http://bitbucket.org/krisvale/stacklesslib

First, I'd like to address your original points:


> -----Original Message-----
> From: stackless-bounces at stackless.com [mailto:stackless-
> bounces at stackless.com] On Behalf Of Richard Tew
> Sent: 3. september 2013 22:52
> To: The Stackless Python Mailing List
> Subject: Re: [Stackless] stacklesslib.async
> 
> Then there are your decorators in your original post.  I look at them, and I
> don't quite feel they are the right approach.  Firstly, when you wrap a
> function with them, if that function is general purpose, then isn't it now
> locked into the async system and no longer suitable for calls made from
> outside of it?
Well, yes, that is sort of the point of decorators.  They help you make a certain kind of function.
In this case, it is to help you create an "async" function, which requires certain calling semantics.
The other case is to make a "task" function, that runs on a separate tasklet.

>  And secondly, the functions they wrap look like synchronous
> functions when actually called, despite now being magicked into some
> magical task creation that works on in the background while returning to the
> original function.
Agreed.  In C#, this is mitigated by recommending a naming convention.
Functions that return "Task" objects usually end with "Async".  We could well use that
convention as a moniker.


> 
> I'm still not clear on why indexes are returned, rather than tasks directly.
Right, I have removed those.  You can just key by Tasks if you want.


Remember, the original reason I started looking at this was to implement the "Async" convention,
i.e. function calls that are synchronous until they themselves block, in which case a "Task" is returned to the caller.  I wanted to see if this kind of explicit scheduling were beneficial to programs, perhaps reducing latency and bringing other goodies.  The rest of the stuff, supporting Tasks, sort of came as an extra.

But now for the second part of the news:
I realized that Python 3 already has concurrent.futures.  And so, I present to you: stacklesslib.futures, for python 2.7.
It is now in, with an identical API, and the unittests adopted from 3.
Because it is standard python api, I don't think we need to bikeshed much about function names and so on.
It supports both tasklet futures and thread futures, allowing you to fork off work to worker threads, e.g. when doing blocking stuff.
There is no multiprocessing futures yet.  But that ought to be simple to add.

However, as it is, the module lacks some of the convenience goodies I'd like to see.  (this is on purpose, since it is a first shot and I wanted compatibility).
For instance, I'd like to add decorators, to help create future-returning methods.
Also, in doing this, I lost track of the original goal, which was to create the Async calling convention (with explicit scheduling) from C#.  But that ought to be simple to do.

So, now we have two futures-like apis, for you to peruse in stacklesslib: stacklesslib.async, and stacklesslib.futures.

Cheers,

K