[Stackless] stacklesslib.async
Christian Tismer
tismer at stackless.com
Sun Oct 13 15:00:55 CEST 2013
Hi Kristjan,
thanks for this pointer, very good article!
Maybe we should talk about futures, await and async.
Not sure where this all ends up, but fascinating.
ciao - chris
On 09.09.13 12:41, Kristján Valur Jónsson wrote:
>
> weeeeelll
>
> What actually led me on this path was this excellent blog post showing
> what is wrong with JS and how C#Async makes things human readable again J
>
> http://tirania.org/blog/archive/2013/Aug-15.html
>
> I’m still working on the “ Task based” model, takin into account some
> of Richard’s previous comments here,
>
> and experinmenting with the “Async and await” thing at the same time.
> I’ll show you something soon, hopefully even with useful code.
>
> Then, Python 3 already has “futures”. One of the things I wanted to
> do was to create a “tasklet” future plugin to that, and port the
> future module back to 2.7
>
> There were some issues with that, I think I arrived at the conclusion
> that the futures model was too complicated, or something….
>
> *From:*stackless-bounces at stackless.com
> [mailto:stackless-bounces at stackless.com] *On Behalf Of *lars van Gemerden
> *Sent:* 7. september 2013 08:06
> *To:* The Stackless Python Mailing List
> *Subject:* Re: [Stackless] stacklesslib.async
>
> without examining the details, i am not sure if this achieves the same
> thing but this reminds me somewhat of the promises and deferreds in
> the javascript dojo library:
> http://dojotoolkit.org/reference-guide/1.9/dojo/Deferred.html.
>
> e.g. i use this in:
>
> getObject: function(way, path, callback){
>
> return xhr.get("/object/"+way+"/"+path, {
>
> handleAs:"json"
>
> })*.then*(function(json_object){
>
> callback(json_object);
>
> }, function(err){
>
> console.error(err);
>
> });
>
> },
>
> xhr.get() is an AJAX call and the result of the call is handeled async
> in the then() method. I have no idea how this is implemented in js,
> but i like the api as being intuitive.
>
> You can also chain these so called promises:
> some_func_returning_promise().then().then().then()
>
> Cheers, Lars
>
> On Wed, Sep 4, 2013 at 12:52 AM, Richard Tew <richard.m.tew at gmail.com
> <mailto:richard.m.tew at gmail.com>> wrote:
>
> I think that unless you are intentionally presenting an identical API,
> using classes as a namespacing extension as they do in C# and Java is
> probably avoided. When I program in C# and Java, I often get the
> feeling that they do things some ways because they have to, because
> they don't have better fitting alternatives.
>
> I do not find function names beginning with "when" intuitive, and find
> it hard to suggest better alternatives as they just confuse me and I
> am not quite sure what they are supposed to do.
>
> Whether you are polling to see if things are ready, or getting what
> they have made ready, deciding on the best function name seems like
> something best considered with all things in mind. Like whether you
> want the call to wait with a timeout. Whether exceptions are raised
> or returned.
>
> The C# exception wrapping has always seemed like an approach they have
> adopted because of architectural limitations.
>
> I would rather the following was done:
>
> for task in tasks:
> try:
> result = task.invoke_result()
> except:
> # handle
>
> I chose invoke rather than get, because it is more evocative of the
> result also reasonably being an exception.
>
> Other approaches could force complexity in order to be able to provide
> "helper" methods, when it might be worth considering whether it is
> possible to avoid them in the first place.
>
> Or:
>
> try:
> result = async.invoke_one_result_picked_out_at_random(tasks)
> except:
> # handle
>
> .. where a task with a result or error returns or raises respectively,
> as a successful result of a call choosing that task.
>
> 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? 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.
>
> I'm still not clear on why indexes are returned, rather than tasks
> directly.
>
> For a lot of this, I think that best choices can be made in view of a
> complete list of intended functionality. Something like:
>
> Lists of tasks:
> - Get all results for a list of tasks, whether returned or exceptions
> raised.
> - Get one result from a list of tasks, whether returned or exceptions
> raised.
> - Get the set of completed tasks from a list of tasks.
>
> Per-task:
> - Get the result, whether returned or exception raised.
>
> Does there have to be timeout functionality for these calls? I think
> there does. How is that handled?
>
>
>
> On Wed, Sep 4, 2013 at 1:25 AM, Kristján Valur Jónsson
> <kristjan at ccpgames.com <mailto:kristjan at ccpgames.com>> wrote:
> > Thanks for your feedback.
> > The original "Task" interface in C# is perhaps not something we need
> to closely follow.
> > As I understand it, "task based asynchronous programming" came
> before the "await" semantics.
> > It makes a distinction between waiting for a result, and returning
> its value. Although Wait will throw an exception if task execution
> throws an exception....
> > So anyway, I _think_ that in C# you
> > t.Wait()
> > return t.Result
> >
> > which separates these things awkwardly.
> >
> > In my implementation of async.Task, I added a get_result() which
> combines the two.
> >
> > I think it makes sense to create a module function,
> get_all_results() which operates on an iterable of Tasks. and returns
> a list of actual values, or raises an exception
> > This can be augmented with a "when_all_results()" function which
> returns a Task object.
> > Simlilarly "get_any_result()" returning an index and value, and
> "when_any_result"
> >
> > This could then be used in preference to the Task-like WaitAll or
> WaitAny et al.
> >
> > I also think I prefer module global functions to class methods, what
> do you think?
> >
> > One interesting thing that .NET does, and these functions, is that
> they throw "AggregateException" wrapping the original error. "await"
> does not.
> > Do you have any thought on that?
> >
> > See:
> >
> >
> http://stackoverflow.com/questions/18314961/i-want-await-to-throw-aggregateexception-not-just-the-first-exception
> >
> >
> >
> >> -----Original Message-----
> >> From: stackless-bounces at stackless.com
> <mailto:stackless-bounces at stackless.com> [mailto:stackless-
> <mailto:stackless->
> >> bounces at stackless.com <mailto:bounces at stackless.com>] On Behalf Of
> Richard Tew
> >> Sent: 2. september 2013 23:06
> >> To: The Stackless Python Mailing List
> >> Subject: Re: [Stackless] stacklesslib.async
> >>
> >> I think this general sort of functionality has long been needed in
> Stackless,
> >> and it brings up the old sawhorse of why are we not including
> stacklesslib in
> >> Stackless distribution. But let's ignore that for now.
> >>
> >> I like the idea of having a standard well received API from another
> popular
> >> language, that people can just pick up and use with approximately same
> >> namespace - even if the coding standards for this specific API
> conflict with
> >> the rest of the package.
> >>
> >> That said I don't get the API. It seems badly designed.
> >>
> >> To me, not having looked at the C# API much, I expect waitAll and
> waitAny
> >> should return the result of the tasks that completed with the index
> of each in
> >> the list.
> >>
> >> [ (0, text), ] = x.waitAny([ t1, t2 ])
> >>
> >> And whenAll and whenAny should imply there's a result, but not pull it.
> >>
> >> [ 0 ] = async.whenAny([ t1, t2 ])
> >>
> >> Then again, why return indexes. That just means you have to waste time
> >> holding onto the original list, if you do not have a permanent one.
> >>
> >> But I think that this should not just handle tasklet completion, it
> should also
> >> handle tasklets producing results via channels. In that case, it
> is useful to poll
> >> whether any tasklets have results, rather than waitX with a minimum
> >> timeout.
> >>
> >> I think that this should be in, but there surely can be a more
> natural fit. And
> >> this might mean a requirement for lower level support.
> >>
> >> And having written all this, the elephant in the room is that I
> believe CSP,
> >> which Andrew Francis has long been advocating, is closer to what I
> think we
> >> need. However, I've long had problems with using it ad hoc, as I
> think it is not
> >> that user friendly and is more theoretically balanced than functionally
> >> balanced.
> >>
> >> Cheers,
> >> Richard.
> >>
> >> _______________________________________________
> >> Stackless mailing list
> >> Stackless at stackless.com <mailto:Stackless at stackless.com>
> >> http://www.stackless.com/mailman/listinfo/stackless
> >
> >
> >
> > _______________________________________________
> > Stackless mailing list
> > Stackless at stackless.com <mailto:Stackless at stackless.com>
> > http://www.stackless.com/mailman/listinfo/stackless
>
> _______________________________________________
> Stackless mailing list
> Stackless at stackless.com <mailto:Stackless at stackless.com>
> http://www.stackless.com/mailman/listinfo/stackless
>
>
>
> --
> ====================================
> Lars van Gemerden
> lars at rational-it.com <mailto:lars at rational-it.com>
> +31 6 26 88 55 39
> ====================================
>
>
>
> _______________________________________________
> Stackless mailing list
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless
--
Christian Tismer :^) <mailto:tismer at stackless.com>
Software Consulting : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/
14482 Potsdam : PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776 fax +49 (30) 700143-0023
PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04
whom do you want to sponsor today? http://www.stackless.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stackless.com/pipermail/stackless/attachments/20131013/d19b47c0/attachment-0001.html>
More information about the Stackless
mailing list