[Python-ideas] fork

[Sven R. Kunze]

On 12.08.2015 05:06, Andrew Barnert wrote:
> 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. 

I think I found a better solution. Not functions should be the 
boundaries but try: blocks.

Why? Because they mark the boundaries for exception handling and this is 
what the problem is about.

I started another thread here: 
https://mail.python.org/pipermail/python-list/2015-August/695313.html


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.

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. ;) )


Some example ('function' here mean stack frame of a function):


def b():
     return 'a string'

try:
     function:
         a = fork(b)
         a += 3
     function:
         b = 5
         b *= 4 * a
except TypeError:
     print('damn, I mixed strings and numbers')


The given try: block needs to make sure if eventually collects all 
exceptions that would have been raised in the sequential case.

Conclusion: the approach is compromise between:

1) deferred evaluation (later is better)
2) proper exception handling (early is better)


Best,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150812/0a2b7ab4/attachment.html>