On Tue, Mar 3 at 19:25:21 Guido van Rossum <guido@python.org> wrote:
On Tue, Mar 3, 2009 at 5:15 PM, Brett Cannon <brett@python.org> wrote:
On Tue, Mar 3, 2009 at 05:13, <rdmurray@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