Hello, It's quite funny, this blog post about C# async also reminds me something. The C# async feature really ressembles Twisted's inlineCallbacks. The C# "async" qualifier seems to map to Twisted's "inlineCallback" decorator and "awaits" is just a "yield" in Twisted. That's how they "mark explicitly" the points in the code where asynchronicity occurs.
Sylvain 2013/9/9 Kristján Valur Jónsson <[email protected]> > 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:* [email protected] [mailto: > [email protected]] *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 <[email protected]> > 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 > <[email protected]> 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: [email protected] [mailto:stackless- > >> [email protected]] 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 > >> [email protected] > >> http://www.stackless.com/mailman/listinfo/stackless > > > > > > > > _______________________________________________ > > Stackless mailing list > > [email protected] > > http://www.stackless.com/mailman/listinfo/stackless > > _______________________________________________ > Stackless mailing list > [email protected] > http://www.stackless.com/mailman/listinfo/stackless**** > > > > **** > > ** ** > > -- > ==================================== > Lars van Gemerden > [email protected] > +31 6 26 88 55 39 > ==================================== **** > > _______________________________________________ > Stackless mailing list > [email protected] > http://www.stackless.com/mailman/listinfo/stackless > -- Sylvain PRAT +33 06 78 71 51 21
_______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
