Jesse Noller wrote: > Per feedback from Guido, the python-dev list and others, I have sent > in an updated version of PEP 371 - the inclusion of the pyprocessing > module into the standard library. > > URL: http://www.python.org/dev/peps/pep-0371/ > > New highlights: > * The module will be renamed to "multiprocessing" > * The API will become PEP 8 compliant My 2 cents on this: PEP 8 compliance in the multiprocessing API is a good idea, but threading should be updated at the same time to provide PEP 8 compliant aliases for the existing names. Using the old Java-based names should provoke a Py3k warning in 2.6 (note: to avoid a runtime performance hit when not using -3, the actual function definitions should be made conditional, rather than checking whether or not to emit the warning every time the legacy API is invoked) The PyGILState_* bug in debug builds that RMO pointed out should also be mentioned in the PEP as something that needs to be fixed in order to implement the PEP. Cheers, Nick. [1] http://bugs.python.org/issue1683 -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4