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.
On Mon, Mar 23, 2009 at 2:00 PM, Jess Austin firstname.lastname@example.org wrote:
On Tue, Mar 3 at 19:25:21 Guido van Rossum email@example.com wrote:
On Tue, Mar 3, 2009 at 5:15 PM, Brett Cannon firstname.lastname@example.org wrote:
On Tue, Mar 3, 2009 at 05:13, email@example.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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org