<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi Kristjan,<br>
<br>
thanks for this pointer, very good article!<br>
Maybe we should talk about futures, await and async.<br>
Not sure where this all ends up, but fascinating.<br>
<br>
ciao - chris<br>
<br>
<br>
On 09.09.13 12:41, Kristján Valur Jónsson wrote:<br>
</div>
<blockquote
cite="mid:EFE3877620384242A686D52278B7CCD3683FD226@RKV-IT-EXCH104.ccp.ad.local"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 14 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">weeeeelll<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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
</span><span
style="font-size:11.0pt;font-family:Wingdings;color:#1F497D">J</span><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><a moz-do-not-send="true"
href="http://tirania.org/blog/archive/2013/Aug-15.html">http://tirania.org/blog/archive/2013/Aug-15.html</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’m still working on the “ Task based”
model, takin into account some of Richard’s previous comments
here,<o:p></o:p></p>
<p class="MsoNormal">and experinmenting with the “Async and
await” thing at the same time. I’ll show you something soon,
hopefully even with useful code.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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<o:p></o:p></p>
<p class="MsoNormal">There were some issues with that, I think I
arrived at the conclusion that the futures model was too
complicated, or something….<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm
0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif""
lang="EN-US">From:</span></b><span
style="font-size:10.0pt;font-family:"Tahoma","sans-serif""
lang="EN-US"> <a class="moz-txt-link-abbreviated" href="mailto:stackless-bounces@stackless.com">stackless-bounces@stackless.com</a>
[<a class="moz-txt-link-freetext" href="mailto:stackless-bounces@stackless.com">mailto:stackless-bounces@stackless.com</a>]
<b>On Behalf Of </b>lars van Gemerden<br>
<b>Sent:</b> 7. september 2013 08:06<br>
<b>To:</b> The Stackless Python Mailing List<br>
<b>Subject:</b> Re: [Stackless] stacklesslib.async<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">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: <a moz-do-not-send="true"
href="http://dojotoolkit.org/reference-guide/1.9/dojo/Deferred.html">http://dojotoolkit.org/reference-guide/1.9/dojo/Deferred.html</a>.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">e.g. i use this in:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"> getObject: function(way,
path, callback){<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> return
xhr.get("/object/"+way+"/"+path, {<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> handleAs:"json"<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> })<b>.then</b>(function(json_object){ <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">
callback(json_object);<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> }, function(err){<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">
console.error(err); <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> });<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> },<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">You can also chain these so called
promises:
some_func_returning_promise().then().then().then() <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Cheers, Lars<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Wed, Sep 4, 2013 at 12:52 AM,
Richard Tew <<a moz-do-not-send="true"
href="mailto:richard.m.tew@gmail.com" target="_blank">richard.m.tew@gmail.com</a>>
wrote:<o:p></o:p></p>
<p class="MsoNormal">I think that unless you are
intentionally presenting an identical API,<br>
using classes as a namespacing extension as they do in
C# and Java is<br>
probably avoided. When I program in C# and Java, I
often get the<br>
feeling that they do things some ways because they have
to, because<br>
they don't have better fitting alternatives.<br>
<br>
I do not find function names beginning with "when"
intuitive, and find<br>
it hard to suggest better alternatives as they just
confuse me and I<br>
am not quite sure what they are supposed to do.<br>
<br>
Whether you are polling to see if things are ready, or
getting what<br>
they have made ready, deciding on the best function name
seems like<br>
something best considered with all things in mind.
Like whether you<br>
want the call to wait with a timeout. Whether
exceptions are raised<br>
or returned.<br>
<br>
The C# exception wrapping has always seemed like an
approach they have<br>
adopted because of architectural limitations.<br>
<br>
I would rather the following was done:<br>
<br>
for task in tasks:<br>
try:<br>
result = task.invoke_result()<br>
except:<br>
# handle<br>
<br>
I chose invoke rather than get, because it is more
evocative of the<br>
result also reasonably being an exception.<br>
<br>
Other approaches could force complexity in order to be
able to provide<br>
"helper" methods, when it might be worth considering
whether it is<br>
possible to avoid them in the first place.<br>
<br>
Or:<br>
<br>
try:<br>
result =
async.invoke_one_result_picked_out_at_random(tasks)<br>
except:<br>
# handle<br>
<br>
.. where a task with a result or error returns or raises
respectively,<br>
as a successful result of a call choosing that task.<br>
<br>
Then there are your decorators in your original post. I
look at them,<br>
and I don't quite feel they are the right approach.
Firstly, when you<br>
wrap a function with them, if that function is general
purpose, then<br>
isn't it now locked into the async system and no longer
suitable for<br>
calls made from outside of it? And secondly, the
functions they wrap<br>
look like synchronous functions when actually called,
despite now<br>
being magicked into some magical task creation that
works on in the<br>
background while returning to the original function.<br>
<br>
I'm still not clear on why indexes are returned, rather
than tasks directly.<br>
<br>
For a lot of this, I think that best choices can be made
in view of a<br>
complete list of intended functionality. Something
like:<br>
<br>
Lists of tasks:<br>
- Get all results for a list of tasks, whether returned
or exceptions raised.<br>
- Get one result from a list of tasks, whether returned
or exceptions raised.<br>
- Get the set of completed tasks from a list of tasks.<br>
<br>
Per-task:<br>
- Get the result, whether returned or exception raised.<br>
<br>
Does there have to be timeout functionality for these
calls? I think<br>
there does. How is that handled?<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal"><br>
<br>
On Wed, Sep 4, 2013 at 1:25 AM, Kristján Valur
Jónsson<br>
<<a moz-do-not-send="true"
href="mailto:kristjan@ccpgames.com">kristjan@ccpgames.com</a>>
wrote:<br>
> Thanks for your feedback.<br>
> The original "Task" interface in C# is perhaps
not something we need to closely follow.<br>
> As I understand it, "task based asynchronous
programming" came before the "await" semantics.<br>
> 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....<br>
> So anyway, I _think_ that in C# you<br>
> t.Wait()<br>
> return t.Result<br>
><br>
> which separates these things awkwardly.<br>
><br>
> In my implementation of async.Task, I added a
get_result() which combines the two.<br>
><br>
> 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<br>
> This can be augmented with a
"when_all_results()" function which returns a Task
object.<br>
> Simlilarly "get_any_result()" returning an
index and value, and "when_any_result"<br>
><br>
> This could then be used in preference to the
Task-like WaitAll or WaitAny et al.<br>
><br>
> I also think I prefer module global functions
to class methods, what do you think?<br>
><br>
> One interesting thing that .NET does, and these
functions, is that they throw "AggregateException"
wrapping the original error. "await" does not.<br>
> Do you have any thought on that?<br>
><br>
> See:<br>
><br>
> <a moz-do-not-send="true"
href="http://stackoverflow.com/questions/18314961/i-want-await-to-throw-aggregateexception-not-just-the-first-exception"
target="_blank">
http://stackoverflow.com/questions/18314961/i-want-await-to-throw-aggregateexception-not-just-the-first-exception</a><br>
><br>
><br>
><br>
>> -----Original Message-----<br>
>> From: <a moz-do-not-send="true"
href="mailto:stackless-bounces@stackless.com">stackless-bounces@stackless.com</a>
[mailto:<a moz-do-not-send="true"
href="mailto:stackless-">stackless-</a><br>
>> <a moz-do-not-send="true"
href="mailto:bounces@stackless.com">bounces@stackless.com</a>]
On Behalf Of Richard Tew<br>
>> Sent: 2. september 2013 23:06<br>
>> To: The Stackless Python Mailing List<br>
>> Subject: Re: [Stackless] stacklesslib.async<br>
>><br>
>> I think this general sort of functionality
has long been needed in Stackless,<br>
>> and it brings up the old sawhorse of why
are we not including stacklesslib in<br>
>> Stackless distribution. But let's ignore
that for now.<br>
>><br>
>> I like the idea of having a standard well
received API from another popular<br>
>> language, that people can just pick up and
use with approximately same<br>
>> namespace - even if the coding standards
for this specific API conflict with<br>
>> the rest of the package.<br>
>><br>
>> That said I don't get the API. It seems
badly designed.<br>
>><br>
>> To me, not having looked at the C# API
much, I expect waitAll and waitAny<br>
>> should return the result of the tasks that
completed with the index of each in<br>
>> the list.<br>
>><br>
>> [ (0, text), ] = x.waitAny([ t1, t2 ])<br>
>><br>
>> And whenAll and whenAny should imply
there's a result, but not pull it.<br>
>><br>
>> [ 0 ] = async.whenAny([ t1, t2 ])<br>
>><br>
>> Then again, why return indexes. That just
means you have to waste time<br>
>> holding onto the original list, if you do
not have a permanent one.<br>
>><br>
>> But I think that this should not just
handle tasklet completion, it should also<br>
>> handle tasklets producing results via
channels. In that case, it is useful to poll<br>
>> whether any tasklets have results, rather
than waitX with a minimum<br>
>> timeout.<br>
>><br>
>> I think that this should be in, but there
surely can be a more natural fit. And<br>
>> this might mean a requirement for lower
level support.<br>
>><br>
>> And having written all this, the elephant
in the room is that I believe CSP,<br>
>> which Andrew Francis has long been
advocating, is closer to what I think we<br>
>> need. However, I've long had problems with
using it ad hoc, as I think it is not<br>
>> that user friendly and is more
theoretically balanced than functionally<br>
>> balanced.<br>
>><br>
>> Cheers,<br>
>> Richard.<br>
>><br>
>>
_______________________________________________<br>
>> Stackless mailing list<br>
>> <a moz-do-not-send="true"
href="mailto:Stackless@stackless.com">Stackless@stackless.com</a><br>
>> <a moz-do-not-send="true"
href="http://www.stackless.com/mailman/listinfo/stackless"
target="_blank">
http://www.stackless.com/mailman/listinfo/stackless</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Stackless mailing list<br>
> <a moz-do-not-send="true"
href="mailto:Stackless@stackless.com">Stackless@stackless.com</a><br>
> <a moz-do-not-send="true"
href="http://www.stackless.com/mailman/listinfo/stackless"
target="_blank">http://www.stackless.com/mailman/listinfo/stackless</a><br>
<br>
_______________________________________________<br>
Stackless mailing list<br>
<a moz-do-not-send="true"
href="mailto:Stackless@stackless.com">Stackless@stackless.com</a><br>
<a moz-do-not-send="true"
href="http://www.stackless.com/mailman/listinfo/stackless"
target="_blank">http://www.stackless.com/mailman/listinfo/stackless</a><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">-- <br>
====================================<br>
Lars van Gemerden<br>
<a moz-do-not-send="true"
href="mailto:lars@rational-it.com">lars@rational-it.com</a><br>
+31 6 26 88 55 39<br>
==================================== <o:p></o:p></p>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Stackless mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Stackless@stackless.com">Stackless@stackless.com</a>
<a class="moz-txt-link-freetext" href="http://www.stackless.com/mailman/listinfo/stackless">http://www.stackless.com/mailman/listinfo/stackless</a></pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Christian Tismer :^) <a class="moz-txt-link-rfc2396E" href="mailto:tismer@stackless.com"><mailto:tismer@stackless.com></a>
Software Consulting : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 : *Starship* <a class="moz-txt-link-freetext" href="http://starship.python.net/">http://starship.python.net/</a>
14482 Potsdam : PGP key -> <a class="moz-txt-link-freetext" href="http://pgp.uni-mainz.de">http://pgp.uni-mainz.de</a>
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? <a class="moz-txt-link-freetext" href="http://www.stackless.com/">http://www.stackless.com/</a></pre>
</body>
</html>