[Python-Dev] PEP 371: Additional Discussion

[Jesse Noller]

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