GeezerVison

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.

Ulli