PEP for nondeterminism.

[Terry Reedy]

"Adam DePrince" <adam.deprince at gmail.com> wrote in message 
news:1143263168.4203.31.camel at localhost.localdomain...

I think this should have better been posted to comp.lang.python
My reletively short answer should explain why.

>I frequently find myself in a situation where I wish I could say "the
> execution order of these two lines just doesn't matter."

Having been 'raised' on Dijkstra's non-deterministically ordered guarded 
statememts, I have a certain amount of sympathy, however ....

> Proposed here are two freshly drafted PEP's advocating for the addition
> of nondeterminism as a spring board for future automatic parallelism.
>
> The first calls for core language changes, the second calls for a minor
> (and likely symbolic) change to list comprehension's semantics to better
> support future parallelism.

these two proposals strick me as premature, since currently irrelevant to 
the overwhelming majority of users, misdirected, since they probably will 
not solve future problems, and out-of-date, since they obsoleted by what 
can be and is being done today with no change to the language.

>    any retval:
>        1
>        2+3
>        my_function_that_returns_17()
>    ...
>
>    retval would be assigned [1, 5, 17] Only the order of evaluation
>    is not deterministic.

This should not be a statement, but can be and should be a function.  By 
current trends, it should specifically be a generator function , coded in C 
or calling C helper functions for some particular parallel hardware, which 
does perhaps the following:

def anyorder(*funcs):
    while funcs:
        yield <some return value> # and remove corresponding func from 
funcs

>    first retval:
>         urllib.open( 'mirror1' ).read()
>         urllib.open( 'mirror2' ).read()
>         urllib.open( 'mirror3' ).read()
>    ....
>
>    retval would contain the data from the fastest mirror, the other
>    threads would be disposed of.

Even more obviously a function.

def firstreturn(*funcs):
    return <first available value>

>    We change the semantics of a the list comprehension to
>    explicitly state that the order of evaluation is
>    non-deterministic, and that there should exist no dependencies or
>    side effects.  This leaves open the potential for future
>    parallelization.

Silly to me because

0) Only people who need non-determinism should be concerned about it.

1) The order *is* deterministic and will be for CPython for at least 2.X 
and probably 3.X, and hence the false claim will be ignored and/or laughed 
at.

2a) Many list operations and iterators are potentially parallel, not just 
list comps.  Indeed, list comps combine and can be rewritten as map and 
filter which can, when possible and appropriate, be replaced with parallel 
versions now.  No 'symbolic' declaration needed.

2b) For another example, Google uses a proprietary map_reduce function (in 
C, with Java, Python, and perhaps other wrappers) to run map followed by 
reduce in parallel on thousands of machines in their proprietary server 
plantations.

Terry Jan Reedy