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
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