Re: parallel processing in standard library

Emin.shopper Martinian.shopper wrote: > Is there any hope of a parallel processing toolkit being > incorporated into the python standard library? I've seen a wide > variety of toolkits each with various features and limitations. > Unfortunately, each has its own API. For coarse-grained > p

Re: parallel processing in standard library

Emin.shopper Martinian.shopper wrote: > On Dec 27, 2007 4:13 PM, Robert Kern <[EMAIL PROTECTED] > > wrote: > My recommendation to you is to pick one of the smaller > implementations that > solves the problems in front of you. Read and understand that module >

Re: parallel processing in standard library

Stefan Behnel wrote: > Robert Kern wrote: >> The problem is that for SQL databases, there is a substantial API that they >> can >> all share. The implementations are primarily differentiated by other factors >> like speed, in-memory or on-disk, embedded or server, the flavor of SQL, etc. >> and on

Re: parallel processing in standard library

I think we are a ways off from the point where any of the solutions are well used, matured, and trusted to promote as a Python standard module. I'd love to see it happen, but even worse than it never happening is it happening too soon. On Dec 27, 2007 8:52 AM, Emin.shopper Martinian.shopper <[EMAI

Re: parallel processing in standard library

On Dec 27, 2007 4:13 PM, Robert Kern <[EMAIL PROTECTED]> wrote: > Emin.shopper Martinian.shopper wrote: > > If not, is there any hope of something like > > the db-api for coarse grained parallelism (i.e, a common API that > > different toolkits can support)? > > The problem is that for SQL databas

Re: parallel processing in standard library

Christian Heimes wrote: > Stefan Behnel wrote: > > Well, there is one parallel processing API that already *is* part of > stdlib: >> the threading module. So the processing module would fit just nicely into the >> idea of a "standard" library. > > Don't you forget the select module and its siblin

Re: parallel processing in standard library

Stefan Behnel wrote: > Well, there is one parallel processing API that already *is* part of stdlib: > the threading module. So the processing module would fit just nicely into the > idea of a "standard" library. Don't you forget the select module and its siblings for I/O bound concurrency? Chris

Re: parallel processing in standard library

Robert Kern wrote: > The problem is that for SQL databases, there is a substantial API that they > can > all share. The implementations are primarily differentiated by other factors > like speed, in-memory or on-disk, embedded or server, the flavor of SQL, etc. > and only secondarily differentiate

Re: parallel processing in standard library

Emin.shopper Martinian.shopper wrote: > Dear Experts, > > Is there any hope of a parallel processing toolkit being incorporated > into the python standard library? I've seen a wide variety of toolkits > each with various features and limitations. Unfortunately, each has its > own API. For coarse-g

parallel processing in standard library

Dear Experts, Is there any hope of a parallel processing toolkit being incorporated into the python standard library? I've seen a wide variety of toolkits each with various features and limitations. Unfortunately, each has its own API. For coarse-grained parallelism, I suspect I'd be pretty happy