[issue3093] Namespace polution from multiprocessing

Changes by Jesse Noller : -- assignee: -> jnoller ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue3093] Namespace polution from multiprocessing

Martin v. Löwis <[EMAIL PROTECTED]> added the comment: Alternatively, I think the _multiprocessing module should be rewritten to use a single C file only, and make all symbols except its init function static. I agree with Adam that the current code needs to be fixed, one way or the other. -

[issue3093] Namespace polution from multiprocessing

Adam Olsen <[EMAIL PROTECTED]> added the comment: The directory is irrelevant. C typically uses a flat namespace for symbols. If python loads this library it will conflict with any other libraries using the same name. This has happened numerous times in the past, so there's no questioning the

[issue3093] Namespace polution from multiprocessing

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Is this really that much of an issue? multiprocessing lives in it's own directory and isn't part of the Python public API. -- nosy: +benjamin.peterson ___ Python tracker <[EMAIL PROTECTED]>

[issue3093] Namespace polution from multiprocessing

Changes by Jesse Noller <[EMAIL PROTECTED]>: -- nosy: +jnoller, roudkerk ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-list

[issue3093] Namespace polution from multiprocessing

New submission from Adam Olsen <[EMAIL PROTECTED]>: All these in multiprocessing.h are lacking suitable py/_py/Py/_Py/PY/_PY prefixes: PyObject *mp_SetError(PyObject *Type, int num); extern PyObject *pickle_dumps; extern PyObject *pickle_loads; extern PyObject *pickle_protocol; extern PyObject *