[Python-Dev] PEP 371: Additional Discussion (original) (raw)

Jesse Noller jnoller at gmail.com
Thu Jun 5 15:15:51 CEST 2008

On Thu, Jun 5, 2008 at 8:59 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

Guido van Rossum wrote:

Sounds good. (Maybe you want to contribute a patch to threading.py? Your implementation notes are important. It could be quite independent from PEP 371.) I created issue 3042 as an RFE to add PEP 8 compliant aliases to the threading module (including the notes about how to avoid the runtime performance hit on the old names). Jesse may want to reference that from the PEP as well. I'm not sure I'll be able to get to it for the first beta though - I'm about to go away for a few days, and plan to enjoy my computer-free holiday :) Cheers, Nick. http://bugs.python.org/issue3042

I'll add it to the PEP. I had to take a day to do "real work" so I can circle back to this today. The continuing outstanding question is if we should put Processing into 2.6 with the threading-like API or PEP 8 compliant names. Richard has already converted the package to PEP 8 style naming, which means I'll need to add aliases to for the original API.

Ideally, both threading and processing would loose the non-PEP 8 APIs in py3k or 2.7

Before I go back to the PEP though - I'd like to see if we can reach some consensus on the API naming. My personal thought is that for many tasks, the processing module is a drop-in replacement (I had to do this very thing yesterday) which means that putting it in with an API which matches the current threading module's API is a Good Thing. However, the flip side of this is that no one really "likes" the threading API as-is, so putting the module into the standard library with the matching API simply adds another "broken" API.

Other than the API naming - I don't think there are any other issues which need to be addressed, minus some cleanup within the PEP for consistency.

-Jesse

More information about the Python-Dev mailing list