A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2008-June/080031.html below:

[Python-Dev] PEP 371: Additional Discussion

[Python-Dev] PEP 371: Additional Discussion [Python-Dev] PEP 371: Additional DiscussionNick Coghlan ncoghlan at gmail.com
Wed Jun 4 12:33:07 CEST 2008
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
More information about the Python-Dev mailing list

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