Guido van Rossum wrote:
On Wed, Mar 25, 2009 at 5:46 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Having helped with that kind of rename once (and for a relatively small API at that), I'd want a *really* compelling reason before ever going through it again - it's messy, tedious and a really good way to burn volunteer time without a great deal to show for it at the end.
My first response was "in hindsight we shouldn't have done this."
Even in hindsight, I think our reasons for providing a PEP 8 compliant threading API are sound. But the experience still makes me cautious of doing it again.
But we moved a bunch of other modules around too (urllib, http, db, I forget what else) and I think those worked out well.
For everything else, we just changed the module name or location. The test suite is pretty good at finding any relevant imports that need to be fixed, and 2to3 is also pretty good at handling them for third party code. The threading module was different in that we actually wanted to change the API of the module itself rather than just where to find it.
Why was threading particularly unpleasant? (An no, this isn't a rhetorical question or a retort. I'm just curious -- I have the same feeling but can't pin it down.)
I think the main thing that may be putting me off is the amount of energy that went into deciding whether or not to emit Py3k warnings or DeprecationWarning or PendingDeprecationWarning for use of the old threading API. The difficulty of that decision strongly flavours my recollection of the whole process even though the final solution chosen was quite simple (maintain the two APIs in parallel, with a couple of notes in the documentation about the situation). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------