On Wed, Mar 25, 2009 at 5:46 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Guido van Rossum wrote:
Please don't do this. We need stable APIs. Trying to switch the entire community to use CapWord APIs for something as commonly used as datetime sounds like wasting a lot of cycles with no reason except the mythical "PEP 8 conformance". As I said, it's a pity we didn't change this at the 3.0 point, but I think going forward we should try to be more committed to slow change. Additions of new functionality are of course fine. But renamings (even if the old names remain available) are just noise.
Even for 3.0, the only API I can recall doing this for was the threading module, and there we had the additional motivation of being able to add multiprocessing with only a PEP 8 compliant API while still having it be close to a drop-in replacement for the corresponding threading API.
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." But we moved a bunch of other modules around too (urllib, http, db, I forget what else) and I think those worked out well. 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.) -- --Guido van Rossum (home page: http://www.python.org/~guido/)