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 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... > > -- > Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick >
See the Manager documentation: http://pyprocessing.berlios.de/doc/manager-objects.html And the Listener/Client documentation: http://pyprocessing.berlios.de/doc/connection-ref.html Remote access is not implicit - it is explicit - you must spawn a Manager/Client instance and tell it to use the network instead of it being "always networked". I'll add a security audit to the list of open issues though - that's a good point. -jesse _______________________________________________ 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
