On Tue, May 13, 2008 at 09:23:02PM -0400, Tom Pinckney wrote:
-> Why not use MPI? It's cross platform, cross language and very widely
-> supported already. And there're Python bindings already.
MPI requires far more setup than the pyprocessing module does; it's by
no means plug & play.
--titus
Nick Coghlan schrieb:
Alex Martelli wrote:
On Wed, May 21, 2008 at 1:53 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
Putting this functionality in 2.6/3.0 would provide a really
nice incentive to update from Py2.5. It would be a sad
lost opportunity if this module had to wait another coupl
> % make
> cc -c -DNDEBUG -O -I. -IInclude -I./Include -DPy_BUILD_CORE -o
> Modules/python.o ./Modules/python.c
> "/usr/include/sys/feature_tests.h", line 353: #error: "Compiler or
> options invalid for pre-UNIX 03 X/Open applications and pre-2001
> POSIX applications"
> cc: acomp failed for
On Thu, 22 May 2008, "Martin v. Löwis" wrote:
> > I would say that writing portable C code is hard as well, aren't there
> > just more tools that help?
>
> The C compiler in particular. It already gets symbolic constants and
> struct layouts right, something that ctypes can't do (because it doesn't
>> Writing portable ctypes modules is really hard - significantly harder
>> than writing portable C code (although writing non-portable ctypes
>> code is apparently easier than writing non-portable C code).
>
> I would say that writing portable C code is hard as well, aren't there
> just more tool
Alex Martelli wrote:
On Wed, May 21, 2008 at 1:53 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
Putting this functionality in 2.6/3.0 would provide a really
nice incentive to update from Py2.5. It would be a sad
lost opportunity if this module had to wait another couple years.
I feel essen
Martin v. Löwis wrote:
IIRC, it chokes on the attempt to compile assembler code that
has C preprocessor macros in it (can't test it right now).
Could the build process be modified to run the C preprocessor
over the assembly language first?
--
Greg
__
On Wed, May 21, 2008 at 1:53 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> This thread has diverged a bit from the original topic.
>
> I suggest going ahead and adding pyprocessing to the library.
> IMO, its functionality is going to be an essential capability as
> more and more computers ship
> The "csvn" subversion bindings use "ctypesgen" to grovel header files:
> http://code.google.com/p/ctypesgen/
Thanks for the pointer. Looks nice. I've used ctypeslib before, but
it takes a bit of infrastructure building (gcc-xml) before it works.
Bill
__
This thread has diverged a bit from the original topic.
I suggest going ahead and adding pyprocessing to the library.
IMO, its functionality is going to be an essential capability as
more and more computers ship with multiple processors.
At this point, the basic API for pyprocessing seems well
t
On May 21, 2008, at 3:58 PM, Jean-Paul Calderone wrote:
Plus, even if ctypes works, the code might be incorrect, because they
had been assuming structure layouts and symbolic constants that have
just a different definition on some other platform, causing the
extension module to crash.
Writing p
On Wed, 21 May 2008 20:57:33 +0200, "\"Martin v. Löwis\"" <[EMAIL PROTECTED]>
wrote:
As said before, PyOpenGL is an example of an extension that moved from C
code to Python/ctypes, luckily we don't use it, but what if the
maintainers of MySQL-Python or cx_Oracle decide to move to ctypes.
Having
Martin v. Löwis schrieb:
>> As said before, PyOpenGL is an example of an extension that moved from C
>> code to Python/ctypes, luckily we don't use it, but what if the
>> maintainers of MySQL-Python or cx_Oracle decide to move to ctypes.
>> Having the ctypes extension in the stdlib doesn't imply it
Thomas Heller schrieb:
> A.M. Kuchling schrieb:
> > On Mon, May 19, 2008 at 08:50:39PM +0200, Thomas Heller wrote:
> >> Myself I would rather spend my energy to make ctypes more portable, within
> >> my
> >> skills and the platforms I have access to.
> >
> > Someone could run Solaris x86 inside a
> As said before, PyOpenGL is an example of an extension that moved from C
> code to Python/ctypes, luckily we don't use it, but what if the
> maintainers of MySQL-Python or cx_Oracle decide to move to ctypes.
> Having the ctypes extension in the stdlib doesn't imply it runs on any
> platform where
[EMAIL PROTECTED] wrote:
Skip> Maybe the presence of a functioning ctypes (can|might|should|will)
Skip> become the operational definition of "Python runs on platform X".
Michael> And what about platforms like the JVM or CLR?
Sorry, allow me to rephrase:
Maybe the presence of a
Ulrich Berning schrieb:
>
> If porting libffi to AIX, HP-UX, IRIX, Solaris... (especially using
> vendor compilers) would be an easy job, I'm sure it would have been done
> already. If more and more essential packages depend on ctypes, we should
> make a clear statement, that Python isn't suppo
A.M. Kuchling schrieb:
> On Mon, May 19, 2008 at 08:50:39PM +0200, Thomas Heller wrote:
>> Myself I would rather spend my energy to make ctypes more portable, within my
>> skills and the platforms I have access to.
>
> Someone could run Solaris x86 inside a hosted virtual machine and make
> it ava
Bill Janssen schrieb:
> What happens on those platforms where ctypes doesn't work? Does the
> module fail to import, either because it isn't present, or because it
> can't load the libffi library? Or does it fail silently in some way?
It doesn't compile, and Python's setup.py script removes if a
Michael Foord schrieb:
> James Y Knight wrote:
>>
>> On May 21, 2008, at 11:26 AM, Michael Foord wrote:
>>
>>> And what about platforms like the JVM or CLR?
>>>
>>> Incidentally there were a small but vocal group of Pythonistas who
>>> were (are?) certain that IronPython is not Python because it d
Skip> Maybe the presence of a functioning ctypes (can|might|should|will)
Skip> become the operational definition of "Python runs on platform X".
Michael> And what about platforms like the JVM or CLR?
Sorry, allow me to rephrase:
Maybe the presence of a functioning ctypes (can|mi
On May 21, 2008, at 11:26 AM, Michael Foord wrote:
And what about platforms like the JVM or CLR?
Incidentally there were a small but vocal group of Pythonistas who
were (are?) certain that IronPython is not Python because it doesn't
have [all of...] the C extensions.
It seems likely to b
James Y Knight wrote:
On May 21, 2008, at 11:26 AM, Michael Foord wrote:
And what about platforms like the JVM or CLR?
Incidentally there were a small but vocal group of Pythonistas who
were (are?) certain that IronPython is not Python because it doesn't
have [all of...] the C extensions.
[EMAIL PROTECTED] wrote:
Ulrich> Having the ctypes extension in the stdlib doesn't imply it runs
Ulrich> on any platform where python runs.
Maybe the presence of a functioning ctypes (can|might|should|will) become
the operational definition of "Python runs on platform X".
And what
On Wed, May 21, 2008 at 10:11:05AM -0500, [EMAIL PROTECTED] wrote:
> Maybe the presence of a functioning ctypes (can|might|should|will) become
> the operational definition of "Python runs on platform X".
It is not black-or-white, runs or doesn't. PythonD, e.g., runs on DOS,
can use sockets (fro
Ulrich> Having the ctypes extension in the stdlib doesn't imply it runs
Ulrich> on any platform where python runs.
Maybe the presence of a functioning ctypes (can|might|should|will) become
the operational definition of "Python runs on platform X".
Skip
__
Brett Cannon wrote:
On Mon, May 19, 2008 at 2:03 AM, Ulrich Berning
<[EMAIL PROTECTED]> wrote:
Gregory P. Smith wrote:
On Fri, May 16, 2008 at 1:32 AM, Ulrich Berning
<[EMAIL PROTECTED]> wrote:
As long as the ctypes extension doesn't build on major Un*x platforms
(AIX,
HP-UX)
Martin v. Löwis schrieb:
I can neither find recvfd in my man pages nor in my header files in
/usr/include on Linux (Ubuntu 8.04 i686). I assume recvfd and sendfd
aren't syscalls but the proposed names for the functions.
Yes (and no). The system call is sendmsg, with a cmsg_type of
SCM_RIGHTS. I
> Could it be a solution to build libffi with gcc, then configure Python
> with '--with-system--ffi' and compile with the sun compiler, or would this
> introduce the dependencies on libgcc or whatever again that Ulrich wanted
> to avoid?
It depends on the processor and the code, but chances are hi
Martin v. Löwis schrieb:
>>> We actually have a couple of Solaris buildbots already - as I
>>> understand it, the issue there isn't Solaris as such, it's being able
>>> to use the Sun compiler instead of GCC to compile ctypes/libffi.
>>
>> Does that mean that we need access to the Sun compiler or
>> We actually have a couple of Solaris buildbots already - as I
>> understand it, the issue there isn't Solaris as such, it's being able
>> to use the Sun compiler instead of GCC to compile ctypes/libffi.
>
> Does that mean that we need access to the Sun compiler or that the Sun
> compiler has bu
> I can neither find recvfd in my man pages nor in my header files in
> /usr/include on Linux (Ubuntu 8.04 i686). I assume recvfd and sendfd
> aren't syscalls but the proposed names for the functions.
Yes (and no). The system call is sendmsg, with a cmsg_type of
SCM_RIGHTS. I don't think there is
Christian Heimes wrote:
I assume recvfd and sendfd
aren't syscalls but the proposed names for the functions.
Yes, the functionality in question is accessed through
the sendmsg() and recvmsg() system calls.
--
Greg
___
Python-Dev mailing list
Python-D
> > Does that mean that we need access to the Sun compiler or that the Sun
> > compiler has bugs which prevent ctypes from compiling?
> >
> I don't think anyone's mentioned Solaris in this context, but there are
> claims that libffi "doesn't build" for AIX and HP-UX.
I think there was also an i
Ted Leung wrote:
On May 20, 2008, at 2:03 PM, Nick Coghlan wrote:
We actually have a couple of Solaris buildbots already - as I
understand it, the issue there isn't Solaris as such, it's being able
to use the Sun compiler instead of GCC to compile ctypes/libffi.
Does that mean that we need
On May 20, 2008, at 2:03 PM, Nick Coghlan wrote:
We actually have a couple of Solaris buildbots already - as I
understand it, the issue there isn't Solaris as such, it's being
able to use the Sun compiler instead of GCC to compile ctypes/libffi.
Does that mean that we need access to the S
Ted Leung wrote:
On May 19, 2008, at 7:47 PM, Steve Holden wrote:
OK, I know people in Sun and possibly H-P I could ask, and I may have
an arm or two to twist to get to IBM. But worst-case, what budget
would the infrastructure committee need for the hardware and (more
importantly) if the ha
r.m.oudkerk schrieb:
> Now that socket.fromfd() and socket._dup() is available on Windows in
> 2.6 and 3.0 (after a patch from me) some of the code could be removed.
> I would also like to see recvfd() and sendfd() get added to the socket
> module -- these functions allow the transfer of file descr
> Bill Janssen schrieb:
> >> Hmm, perhaps the ctypes documentation could use a more prominent warning
> >> that it may not be available on some Unix platforms (HP-UX, AIX, IRIX),
> >> and that it may require the use of GCC rather than the vendor compiler
> >> on others (Solaris).
> >>
> >> At t
Steve Holden wrote:
> The more libraries that use ctypes to call into native functionality,
> the more important it becomes to have ctypes run, even if only to
> implement platform-specific functionality on the given platforms. I
> would like "being able to call a wide range of native libraries"
On Mon, 19 May 2008, Bill Janssen wrote:
> > On Mon, May 19, 2008 at 5:15 PM, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > >> If you can run a pure Python module
> > >> that does not depend on any C extension, then that platform has the
> > >> support needed to run Python.
> > >
> > > This is certai
On May 19, 2008, at 7:47 PM, Steve Holden wrote:
OK, I know people in Sun and possibly H-P I could ask, and I may
have an arm or two to twist to get to IBM. But worst-case, what
budget would the infrastructure committee need for the hardware and
(more importantly) if the hardware material
Charles Cazabon schrieb:
> A.M. Kuchling <[EMAIL PROTECTED]> wrote:
>> On Mon, May 19, 2008 at 08:50:39PM +0200, Thomas Heller wrote:
>> > Myself I would rather spend my energy to make ctypes more portable, within
>> > my
>> > skills and the platforms I have access to.
>>
>> Someone could run Sol
A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> On Mon, May 19, 2008 at 08:50:39PM +0200, Thomas Heller wrote:
> > Myself I would rather spend my energy to make ctypes more portable, within
> > my
> > skills and the platforms I have access to.
>
> Someone could run Solaris x86 inside a hosted virtual
Bill Janssen wrote:
And these are all SYSV derivatives, aren't they? So perhaps it's some
common fix for all three?
I've never personally had the pleasure(?!) of having to get stuff
working on all of AIX/HP-UX/Tru64/Solaris, but what little dealings I've
had with people who have suggests tha
On Mon, May 19, 2008 at 06:13:11PM -0700, Bill Janssen wrote:
> And these are all SYSV derivatives, aren't they? So perhaps it's some
> common fix for all three?
This reminds of a Tim-ism:
==
> Just for the record, on AIX, the following C program:
Oh no you don't! I followed AIX
Bill Janssen wrote:
On Mon, May 19, 2008 at 5:15 PM, Bill Janssen <[EMAIL PROTECTED]> wrote:
If you can run a pure Python module
that does not depend on any C extension, then that platform has the
support needed to run Python.
This is certainly a point of view. One that many end-users wouldn't
> On Mon, May 19, 2008 at 5:15 PM, Bill Janssen <[EMAIL PROTECTED]> wrote:
> >> If you can run a pure Python module
> >> that does not depend on any C extension, then that platform has the
> >> support needed to run Python.
> >
> > This is certainly a point of view. One that many end-users wouldn'
On Mon, May 19, 2008 at 5:15 PM, Bill Janssen <[EMAIL PROTECTED]> wrote:
>> If you can run a pure Python module
>> that does not depend on any C extension, then that platform has the
>> support needed to run Python.
>
> This is certainly a point of view. One that many end-users wouldn't
> understa
> If you can run a pure Python module
> that does not depend on any C extension, then that platform has the
> support needed to run Python.
This is certainly a point of view. One that many end-users wouldn't
understand :-).
Bill
___
Python-Dev mailing
On Mon, May 19, 2008 at 08:50:39PM +0200, Thomas Heller wrote:
> Myself I would rather spend my energy to make ctypes more portable, within my
> skills and the platforms I have access to.
Someone could run Solaris x86 inside a hosted virtual machine and make
it available to the Python developers.
On Mon, May 19, 2008 at 2:03 AM, Ulrich Berning
<[EMAIL PROTECTED]> wrote:
> Gregory P. Smith wrote:
>
>> On Fri, May 16, 2008 at 1:32 AM, Ulrich Berning
>> <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> As long as the ctypes extension doesn't build on major Un*x platforms
>>> (AIX,
>>> HP-UX), I don't like
Bill Janssen schrieb:
>> Hmm, perhaps the ctypes documentation could use a more prominent warning
>> that it may not be available on some Unix platforms (HP-UX, AIX, IRIX),
>> and that it may require the use of GCC rather than the vendor compiler
>> on others (Solaris).
>>
>> At the moment, I s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A.M. Kuchling wrote:
| Python development doesn't seem to have any volunteers who use AIX or
| HP-UX and can fix bugs on these platforms. Searching bugs.python.org,
| I find about 20 open AIX issues, 4 or 5 HP-UX issues, 6 IRIX bugs, and
| about 15 S
> Hmm, perhaps the ctypes documentation could use a more prominent warning
> that it may not be available on some Unix platforms (HP-UX, AIX, IRIX),
> and that it may require the use of GCC rather than the vendor compiler
> on others (Solaris).
>
> At the moment, I suspect some projects may be
Ulrich Berning wrote:
I'm trying to use the vendor specific compilers whenever possible,
because using gcc puts in additional dependencies (libgcc), I want to
avoid, and even if I could live with these dependencies, it's not easy
to get/build the 'right' gcc version, if your software also depen
Gregory P. Smith wrote:
On Fri, May 16, 2008 at 1:32 AM, Ulrich Berning
<[EMAIL PROTECTED]> wrote:
As long as the ctypes extension doesn't build on major Un*x platforms (AIX,
HP-UX), I don't like to see ctypes dependend modules included into the
stdlib. Please keep the stdlib as portable as
Nick Coghlan wrote:
Ulrich Berning wrote:
More and more people tend to say "Runs on Un*x" when they really mean
"Tested on Linux". Un*x is not Linux.
Hmm, perhaps that would be why there are Solaris, FreeBSD and Tru64
machines amongst the main Python buildbots, to go along with the
assort
On Fri, May 16, 2008 at 1:32 AM, Ulrich Berning
<[EMAIL PROTECTED]> wrote:
>
> As long as the ctypes extension doesn't build on major Un*x platforms (AIX,
> HP-UX), I don't like to see ctypes dependend modules included into the
> stdlib. Please keep the stdlib as portable as possible.
Nice in theo
> Apart from (1) and (2) which I think are unavoidable, nearly all the C
> code is Windows specific. I assume you don't want to bring
> in the whole of pywin32 into stdlib...
I wouldn't structure it the same way as pywin32, but yes, I have
pondered exposing all of Win32 in a module, as part of th
2008/5/14 "Martin v. Löwis" <[EMAIL PROTECTED]>:
>> 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 app
[Facundo]
I think that including in the stdlib a threading-like-API module is a
clear win.
I also think this is vital and should not wait for Py2.7.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
2008/5/13 Jesse Noller <[EMAIL PROTECTED]>:
> 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
+1 to include this module in the library
On Fri, May 16, 2008 at 11:22 AM, Thomas Heller <[EMAIL PROTECTED]> wrote:
> Ulrich Berning schrieb:
>> Nick Craig-Wood wrote:
>>
>>>Jesse Noller <[EMAIL PROTECTED]> wrote:
>>>
>>>
I am looking for any questions, concerns or benchmarks python-dev has
regarding the possible inclusion of th
Ulrich Berning schrieb:
> Nick Craig-Wood 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 - preferably in the 2.6 timelin
Ulrich Berning wrote:
More and more people tend to say "Runs on Un*x" when they really mean
"Tested on Linux". Un*x is not Linux.
Hmm, perhaps that would be why there are Solaris, FreeBSD and Tru64
machines amongst the main Python buildbots, to go along with the
assorted OS X, Windows and Lin
On Fri, May 16, 2008 at 10:32:30AM +0200, Ulrich Berning wrote:
> As long as the ctypes extension doesn't build on major Un*x platforms
> (AIX, HP-UX), I don't like to see ctypes dependend modules included into
> the stdlib. Please keep the stdlib as portable as possible.
> More and more people t
Nick Craig-Wood 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 - preferably in the 2.6 timeline. In March, I began
working on the PEP for
Gregory P. Smith schrieb:
> +0.5 on inclusion. that means i am happy if it does but don't think
> it needs to make it into 2.6/3.0. leave inclusion for 2.7/3.1. its
> easy for people to install from an external source for now if they
> want it.
I'm still -0.5 on inclusion *NOW*, but +1 on incl
Gregory P. Smith wrote:
-1 on "multicore" - multiprocess or multiprocessing are a fine names.
cores are irrelevant. systems have multiple cpus real or virtual
regardless of how many dies, sockets and cores there are.
+0.5 on inclusion. that means i am happy if it does but don't think
it needs
> -1 on "multicore" - multiprocess or multiprocessing are a fine names.
> cores are irrelevant.
Thanks you for saying that. I'm constantly amazed how people think
multi-core systems are a new thing, conceptually, when they are really
just a different packaging for multi-processor systems (perhaps
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
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
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
Nick Coghlan wrote:
Talin wrote:
multiprocessing
multiprocessing would work for me
Me, too.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/
Tom Pinckney wrote:
Why not use MPI? It's cross platform, cross language and very widely
supported already. And there're Python bindings already.
The point of pyprocessing is that fact that the API is the same as that
of the threading module - making it very easy to convert a multithreaded
pr
Talin wrote:
multiprocessing
multiprocessing would work for me - it adds the concurrency implications
that threading has, but 'processing' on its own would be missing.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
multiprocessing
Greg Ewing 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
Sounds good, but I'd suggest giving a more specific
name than "processing", which is
The inclusion of the processing module does not exclude the potential
to also use or one day include MPI bindings.
The goal is to add a module with a "known" API and semantics which
allows programmer using cPython to easily take advantage of multple
cores (and as a side benefit, machines).
Why not use MPI? It's cross platform, cross language and very widely
supported already. And there're Python bindings already.
On May 13, 2008, at 8:52 PM, Jesse Noller wrote:
I am looking for any questions, concerns or benchmarks python-dev has
regarding the possible inclusion of the pyproces
On May 13, 2008, at 8:57 PM, Greg Ewing <[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
Sounds good, but I'd suggest giving a more spec
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
Sounds good, but I'd suggest giving a more specific
name than "processing", which is so generic as to
be meaningless.
--
1 - 100 of 101 matches
Mail list logo
