"Adam DePrince" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
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 -- http://mail.python.org/mailman/listinfo/python-list