[Python-ideas] Python and Concurrency
rrr at ronadam.com
Mon Apr 2 11:01:59 CEST 2007
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
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
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,
More information about the Python-ideas