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

[Guido van Rossum]

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.

--Guido

On Mon, Mar 23, 2009 at 2:00 PM, Jess Austin <jaustin at post.harvard.edu> wrote:
> On Tue, Mar 3 at 19:25:21 Guido van Rossum <guido at python.org> wrote:
>> On Tue, Mar 3, 2009 at 5:15 PM, Brett Cannon <brett at python.org> wrote:
>>>
>>>
>>> On Tue, Mar 3, 2009 at 05:13, <rdmurray at bitdance.com> wrote:
>>>>
>>>> On Tue, 3 Mar 2009 at 06:01, Ivan Krsti?~G wrote:
>>>>>
>>>>> On Mar 2, 2009, at 7:08 PM, Steve Holden wrote:
>>>>>>
>>>>>> > > ?PS.: so is datetime.datetime a builtin then? :)
>>>>>> > > ?Another historic accident. Like socket.socket. :-(
>>>>>> >
>>>>>> ?A pity this stuff wasn't addressed for 3.0. Way too late now, though.
>>
>> A pity indeed.
>>
>>>>> It may be too late to rename the existing accidents, but why not add
>>>>> consistently-named aliases (socket.Socket, datetime.DateTime, etc) and
>>>>> strongly encourage their use in new code?
>>>
>>> Or make the old names aliases for the new names and start a
>>> PendingDeprecationWarning on the old names so they can be switched in the
>>> distant future?
>>
>> +1, if it's not done in a rush and only for high-visibility modules --
>> let's start with socket and datetime.
>>
>> We need a really long lead time before we can remove these. I
>> recommend starting with a *silent* deprecation in 3.1 combined with a
>> PR offensive for the new names.
>
> I've uploaded a patch for the datetime module with respect to this
> issue at http://bugs.python.org/issue5530 . I would appreciate it if
> experienced developers could take a look at it and provide some
> feedback.  Since I've only been hacking on CPython for about a month,
> please be kind!  I'm happy to make changes to this.
>
> As it stands now, the patch changes the current objects to have
> CapWords names, and subclasses these objects to provide objects with
> the old names. Use of methods (including __new__) of the derived
> objects causes PendingDeprecations (if one has warning filters
> appropriately set).
>
> A warning: this patch requires the patch to the test refactoring at
> Issue 5520 to completely apply.  It will fail one test without the
> patch at Issue 5516.  Both of these are (inexpertly) linked from the
> roundup page for this issue.
>
> I hope this will be helpful.
>
> cheers,
> Jess Austin
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)