<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 12.08.2015 05:06, Andrew Barnert wrote:<br>
<blockquote
cite="mid:4A86012D-89FB-4A2E-A0D4-48D9FF09FE33@yahoo.com"
type="cite">
But I'm not sure what good that would do anyway. If you unwrap
futures every time they're returned, they're not doing anything
useful as futures in the first place; you might as well just
return the values directly.
</blockquote>
<br>
I think I found a better solution. Not functions should be the
boundaries but try: blocks.<br>
<br>
Why? Because they mark the boundaries for exception handling and
this is what the problem is about.<br>
<br>
I started another thread here:
<a class="moz-txt-link-freetext" href="https://mail.python.org/pipermail/python-list/2015-August/695313.html">https://mail.python.org/pipermail/python-list/2015-August/695313.html</a><br>
<br>
<br>
If an exception is raised within an try: block that is not supposed
to be handled there, weird things might happen (wrong handling,
superfluous handling, no handling, etc.). Confining the evaluation
of result proxies within the try: blocks they are created in would
basically retain all sequential properties.<br>
<br>
So, plugging in 'fork' and removing it would basically change
nothing (at least if you don't try anything really insane which at
least is disallowed by our coding standards. ;) )<br>
<br>
<br>
Some example ('function' here mean stack frame of a function):<br>
<br>
<br>
def b():<br>
return 'a string'<br>
<br>
try:<br>
function:<br>
a = fork(b)<br>
a += 3<br>
function:<br>
b = 5<br>
b *= 4 * a<br>
except
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
TypeError:<br>
print('damn, I mixed strings and numbers')<br>
<br>
<br>
The given try: block needs to make sure if eventually collects all
exceptions that would have been raised in the sequential case.<br>
<br>
Conclusion: the approach is compromise between:<br>
<br>
1) deferred evaluation (later is better)<br>
2) proper exception handling (early is better)<br>
<br>
<br>
Best,<br>
Sven<br>
</body>
</html>