homepage

PEP 371 highlighted the non-PEP 8 compliant nature of the threading API.
Since part of that PEP involves updating the multiprocessing API to be
PEP 8 compliant before addition the standard library, the threading API
should also be updated to be PEP 8 compliant in 3.0.
That part's easy - the trickier part if to provide both the existing API
and a PEP 8 compliant API in 2.6, with the old names triggering a
warning when run with the -3 switch, but not suffering a performance hit
otherwise.
The trick with that is to define the renamed API's differently depending
on whether or not sys.py3kwarning is set, rather than checking it every
time the old APIs are invoked.
(Left unassigned for the moment, since I'm about to go completely
offline for a few days, so it will be tough for me to get to this before
the first beta)

Is this what you were looking for? (in the patch) What I did could also
be done with metaclasses, but I thought that would be overkill. Warning:
this patch causes test threading to crash when run with the -3 flag.

Attaching a patch which fixes everything.

The code changes in the patch look pretty good to me (although you
probably want to actually use @wraps inside _old_api!)
There are obviously also documentation and test suite changes that will
be needed.

On Thu, Jun 5, 2008 at 8:56 PM, Nick Coghlan <report@bugs.python.org> wrote:
>
> Nick Coghlan <ncoghlan@gmail.com> added the comment:
>
> The code changes in the patch look pretty good to me (although you
> probably want to actually use @wraps inside _old_api!)
That won't work because we are creating the method than we would pass
to wraps. Changing old's __name__ to old_name should do the trick.
>
> There are obviously also documentation and test suite changes that will
> be needed.
Of course. I can do that.

I'd still be inclined to put a @wraps(meth) decorator on the definition
of the wrapper function (and then override to the supplied name
afterwards) - remember that functools.wraps is a decorator factory
rather than a decorator itself. 
That would ensure that any docstrings and the like would be preserved
(granted, it appears the threading module currently doesn't *have* any
docstrings, but it would still be better to write the wrapping code
correctly).

Ok. Pending your acceptance, I'll apply after docs+tests.

Applied in r64125, and r64144.