[Python-Dev] Adding PEP consistent aliases for names that don't currently conform

Guido van Rossum guido at python.org
Thu Mar 26 04:34:31 CET 2009


On Wed, Mar 25, 2009 at 5:46 AM, Nick Coghlan <ncoghlan at 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/)


More information about the Python-Dev mailing list