[Python-Dev] Addition of "pyprocessing" module to standard lib.

Jesse Noller jnoller at gmail.com
Fri May 16 17:33:52 CEST 2008


On Fri, May 16, 2008 at 11:22 AM, Thomas Heller <theller at ctypes.org> wrote:
> Ulrich Berning schrieb:
>> Nick Craig-Wood wrote:
>>
>>>Jesse Noller <jnoller at gmail.com> 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 the pyprocessing (processing)
>>>> module into the python standard library[1]. The original email to the
>>>> stdlib-sig can be found here, it includes a basic overview of the
>>>> module:
>>>>
>>>> http://mail.python.org/pipermail/stdlib-sig/2008-March/000129.html
>>>>
>>>> The processing module mirrors/mimics the API of the threading module -
>>>> and with simple import/subclassing changes depending on the code,
>>>> allows you to leverage multi core machines via an underlying forking
>>>> mechanism. The module also supports the sharing of data across groups
>>>> of networked machines - a feature obviously not part of the core
>>>> threading module, but useful in a distributed environment.
>>>>
>>>>
>>>
>>>I think processing looks interesting and useful, especially since it
>>>works on Windows as well as Un*x.
>>>
>>>However I'd like to see a review of the security - anything which can
>>>run across networks of machines has security implications and I didn't
>>>see these spelt out in the documentation.
>>>
>>>Networked running should certainly be disabled by default and need
>>>explicitly enabling by the user - I'd hate for a new version of python
>>>to come with a remote exploit by default...
>>>
>>>
>>>
>> 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 tend to say "Runs on Un*x" when they really mean
>> "Tested on Linux". Un*x is not Linux.
>
> Hm, I've never looked at the processing module.  Does it depend on ctypes?
>
> Anyway, the trunk version of ctypes is a lot more portable than the release25-maint
> version.  I have once tried to build the trunk on HP-UX machines, and,
> IIRC, it did build on IA64 and PA machines.  Of course only with GCC, not
> with the vendor compilers.
>
> Thomas
>

Yes, it requires ctypes.


More information about the Python-Dev mailing list