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 couple
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 tools that
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
use
% 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
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 high
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.
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), I
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
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 (from
[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
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.
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
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
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.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 available
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 supported
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 doesn't
have [all
[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
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
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 hosted virtual
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 the
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
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
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
___
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 with
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
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
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:
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
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 machine
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 Solaris x86 inside a
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 certainly a point of view.
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 to
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
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
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
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
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
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 issue with
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
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 a
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
assorted
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
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
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
-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
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 suspect some
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 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
understand :-).
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
understand
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
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
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 timeline. In March, I
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 the pyprocessing module to
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,
[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
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 the
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 theory
-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
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
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
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
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. Although
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
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 - preferably in the
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 seems
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 has, whether users
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're
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 not
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
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 of
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
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 multiple
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
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
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 as
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:
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
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 direction, making it
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.
--
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
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
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).
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
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
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
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:
88 matches
Mail list logo
