[Python-ideas] Python and Concurrency

[Ron Adam]

Neil Toronto wrote:

> There's an elephant-in-the-living-room UI problem, here: how would one 
> go about extracting a partial order from a programmer?

Beat him or her with a stick?  Just kidding of course. ;-)

I think what you mean is how can we make it easier for a programmer to 
express their intention.  One way is to provide a rich set of alternatives 
in extension modules and letting them choose.  The ones that work will 
bubble up to the top, and the hard to manage and maintain choices will 
either be improved or forgotten.


> A text editor is fine for a total order, but I can't think of how I'd 
> use one non-messily to define a partial order. How about a Gantt chart
> for a partial order, or some other kind of dependency diagram? How would
> you make it as easy to use as a text editor? The funny thing is, once
> you solve this problem, it may even be *easier* to program this way,
> because rather than maintaining the partial order in your head (or
> inferring it from a total order in the code), it'd be right in front of
> you.

Well, you wouldn't want to interleave several tasks instructions together 
in any fixed (or otherwise) way.  That definitely would not be anything I 
would want to maintain.

Being able to define serial blocks of code to execute in a parallel fashion 
  can make some things easier to express because it gives you another way 
you can group related code together instead of having to split op, or 
combine unrelated, code together because of ordering dependencies.

But addressing your partial order concerns, most likely you will have 
parallel structures communicating to one another with no apparent 
predefined order.  The ordering could be completely dependent on the data 
they get and send to each other, and completely dependent on outside events.

Think of tasks that can open multiple communication channels to other tasks 
as needed.  What order would these be executed in?  Who knows! <shrug>  And 
you may not need to know.

It may be that a partial-order execution order could be considered a subset 
of indeterminate execution order.


> There's no reason a program with partial flow control couldn't have very 
> Python-like syntax. After reading this, though, which formalized what 
> I've long felt is the biggest problem with concurrent programming, I'd 
> have to say it'd definitely not be Python itself.

I think it would still be python.  From what I see Python will continue to 
be improved on for quite some time.  But these ideas must prove themselves 
to be pythonic before they get put in python.

(My spell checker picked out polyphonic for pythonic... PolyPython?)

> For the record, I disagree strongly with the "let's keep concurrency in 
> the libraries" idea. I want to program in *Python*, dangit. Or at least 
> something that feels a lot like it.

My guess, (if/when this is ever added), it will most likely be a 
combination of some basic supporting enhancements to names and objects so 
that they can work with task libraries better, along with one or more 
tasks/multi-processing libraries.

If it turns out that the use of some of these ideas becomes both frequent 
and common.  Then syntax similar to the 'with' statement might find 
support.  But all of this is still quite a ways off unless some (yet to be 
identified) overwhelming need pushes it forward.

Just my two cents,
   _Ron