2.6, 3.0, and truly independent intepreters

Andy O'Meara andy55 at gmail.com
Tue Nov 4 16:27:41 CET 2008

On Nov 4, 9:38 am, sturlamolden <sturlamol... at yahoo.no> wrote:

> First let me say that there are several solutions to the "multicore"
> problem. Multiple independendent interpreters embedded in a process is
> one possibility, but not the only.''

No one is disagrees there.  However, motivation of this thread has
been to make people here consider that it's much more preferable for
CPython have has few restrictions as possible with how it's used.  I
think many people here assume that python is the showcase item in
industrial and commercial use, but it's generally just one of many
pieces of machinery that serve the app's function (so "the tail can't
wag the dog" when it comes to app design).  Some people in this thread
have made comments such as "make your app run in python" or "change
your app requirements" but in the world of production schedules and
making sure payroll is met, those options just can't happen.  People
in the scientific and academic communities have to understand that the
dynamics in commercial software are can be *very* different needs and
have to show some open-mindedness there.

> The multiprocessing package has almost the same API as you would get
> from your suggestion, the only difference being that multiple
> processes is involved.

As other posts have gone into extensive detail, multiprocessing
unfortunately don't handle the massive/complex data structures
situation (see my posts regarding real-time video processing).  I'm
not sure if you've followed all the discussion, but multiple processes
is off the table (this is discussed at length, so just flip back into
the thread history).


More information about the Python-list mailing list