[Python-ideas] fork - other approaches

[Stephen J. Turnbull]

Sven R. Kunze writes:

 > > Exchangeability is a property of the computational structure, not of
 > > the language syntax.

 > It is a property of both and this thread is about the latter. I am glad 
 > ThreadPool and ProcessPool have the same API. That is very helpful.

That's because they *can* have the same API, because the computational
structure is mostly the same, and where it isn't, little to no
confusion is possible.  For example, the fact that a process-oriented
task doesn't lock variables when reading or writing them is unlikely
to matter because that task can't access global objects of the parent
program anyway.  In order to take advantage of that aspect of threads,
you need to rewrite the task.

Perhaps a better way to express what I meant is "Syntax can express
exchangeability already present in the computational structure.  It
cannot impose exchangeability not present in the computational
structure."

 > > In particular, in languages that *have* a for
 > > loop, you're also going to have side effects, and exchangeability will
 > > fail if those side effects interact between problem components.
 > >
 > > Therefore you need at least two syntaxes: one to express sequential
 > > iteration, and one to express parallizable computations.  Since the
 > > "for" syntax in Python has always meant sequential iteration, and the
 > > computations allowed in the suite are unrestricted, you'd just be
 > > asking for trouble.

 > Sorry?

Exactly what I said: you're trying to change a statement that has
always meant sequential iteration of statements containing side
effects like assignments, and have it also mean parallel execution
where side effects need to be carefully controlled.  That will cause
trouble for people reading the code (eg, they now have to understand
any function calls recursively to understand whether there might be
any ambiguities), even if it doesn't necessarily cause trouble for you
writing it.