On Wed, May 14, 2008 at 6:48 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 12:19 PM 5/15/2008 +1200, Greg Ewing wrote:
>>
>> Andrew McNabb wrote:
>>
>>> If it made people feel better, maybe it should be called threading2
>>> instead of multiprocessing.
>>
>> I think that errs in the other dire
At 12:19 PM 5/15/2008 +1200, Greg Ewing wrote:
Andrew McNabb wrote:
If it made people feel better, maybe it should be called threading2
instead of multiprocessing.
I think that errs in the other direction, making it sound
like just another way of doing single-process threading,
which it's not
Greg> Maybe "multicore" would help give the right impression?
"multiproc", "multiprocess"?
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/option
Charles Cazabon wrote:
"threading" is to threads as "processing" is to processes; that's why it was
named processing.
Unfortunately, the word "processing" is already used in the
field of computing with a very general meaning -- any kind
of data transfomation at all can be, and is, referred to a
Andrew McNabb wrote:
If it made people feel better, maybe it should be called threading2
instead of multiprocessing.
I think that errs in the other direction, making it sound
like just another way of doing single-process threading,
which it's not.
Maybe "multicore" would help give the right i
M.-A. Lemburg wrote:
The API of the processing module does look simple and nice, but
parallel processing is a minefield - esp. when it comes to handling
error situations (e.g. a worker failing, network going down, fail-over,
etc.).
What I'm missing with the processing module is a way to spawn p
Andrew McNabb <[EMAIL PROTECTED]> wrote:
>
> Think of the processing module as an alternative to the threading
> module, not as an alternative to MPI. In Python, multi-threading can be
> extremely slow. The processing module gives you a way to convert from
> using multiple threads to using multi
> I really do feel that inclusion of this library offers us the best of
> both worlds - it gives us (as a community) an easy answer to those
> people who would dismiss python due to the GIL and it also allows
> users to easily implement their applications.
I really feel that you can get the best o
On May 14, 2008, at 12:32 PM, Andrew McNabb wrote:
Think of the processing module as an alternative to the threading
module, not as an alternative to MPI. In Python, multi-threading
can be
extremely slow. The processing module gives you a way to convert from
using multiple threads to usi
> In the scientific world, MPI is the standard API of choice for doing
> parallel processing, so if we're after standards, supporting MPI
> would seem to be more attractive than the processing module.
>
> http://pypi.python.org/pypi/mpi4py
Of course, for MPI, pyprocessing's main functionality
On Wed, May 14, 2008 at 08:06:15AM -0400, Jesse Noller wrote:
>
> Overwhelmingly, many of the python programmers I spoke to are looking
> for "a solution" that does not require the alteration of a known
> programming paradigm (i.e: threads) to allow them to take advantage of
> systems which are no
On Wed, May 14, 2008 at 05:46:25PM +0200, M.-A. Lemburg wrote:
>
> What I'm missing with the processing module is a way to spawn processes
> on clusters (rather than just on a single machine).
>
> In the scientific world, MPI is the standard API of choice for doing
> parallel processing, so if we'r
On Wed, May 14, 2008 at 11:46 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> On 2008-05-14 14:15, Jesse Noller wrote:
>>
>> On Wed, May 14, 2008 at 5:45 AM, Christian Heimes <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> Martin v. Löwis schrieb:
>>>
I'm worried whether it's stable, what user base it ha
On 2008-05-14 14:15, Jesse Noller wrote:
On Wed, May 14, 2008 at 5:45 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
Martin v. Löwis schrieb:
I'm worried whether it's stable, what user base it has, whether users
> (other than the authors) are lobbying for inclusion. Statistically,
> it see
Thomas, I think this is related to issue 1348.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Wed, May 14, 2008 at 6:58 AM, Nick Craig-Wood <[EMAIL PROTECTED]> wrote:
> Jesse Noller <[EMAIL PROTECTED]> wrote:
> > I am looking for any questions, concerns or benchmarks python-dev has
> > regarding the possible inclusion of the pyprocessing module to the
> > standard library - prefera
On Wed, May 14, 2008 at 5:45 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis schrieb:
>
> > I'm worried whether it's stable, what user base it has, whether users
> > (other than the authors) are lobbying for inclusion. Statistically,
> > it seems to be not ready yet: it is not e
On Wed, May 14, 2008 at 4:45 AM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Jesse Noller wrote:
> > I am looking for any questions, concerns or benchmarks python-dev has
> > regarding the possible inclusion of the pyprocessing module to the
> > standard library - preferably in the 2.6 timeli
Jesse Noller <[EMAIL PROTECTED]> wrote:
> I am looking for any questions, concerns or benchmarks python-dev has
> regarding the possible inclusion of the pyprocessing module to the
> standard library - preferably in the 2.6 timeline. In March, I began
> working on the PEP for the inclusion of
I was debating whether this was truly a question for python-dev or if I
should take it to one of the user lists. Ultimately it feels like a
question about the implementation of a core module, so hopefully nobody
minds me posting it here. :)
Although not listed as a public API method in the doc
Christian Heimes wrote:
Martin v. Löwis schrieb:
I'm worried whether it's stable, what user base it has, whether users
(other than the authors) are lobbying for inclusion. Statistically,
it seems to be not ready yet: it is not even a year old, and has not
reached version 1.0 yet.
I'm on Martin
Martin v. Löwis schrieb:
> I'm worried whether it's stable, what user base it has, whether users
> (other than the authors) are lobbying for inclusion. Statistically,
> it seems to be not ready yet: it is not even a year old, and has not
> reached version 1.0 yet.
I'm on Martin's side here. Althou
Jesse Noller wrote:
> I am looking for any questions, concerns or benchmarks python-dev has
> regarding the possible inclusion of the pyprocessing module to the
> standard library - preferably in the 2.6 timeline.
I think for inclusion in 2.6 it's to late. For 3.0, it's definitely
too late - the
23 matches
Mail list logo
