Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
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
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@post.harvard.edu> wrote:
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 _______________________________________________ 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
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Tue, Mar 24, 2009 at 3:14 PM, Guido van Rossum <guido@python.org> 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.
OK, I had misunderstood your earlier message. Sorry for the confusion. thanks, Jess
On Tue, Mar 24, 2009 at 1:23 PM, Jess Austin <jaustin@post.harvard.edu> wrote:
On Tue, Mar 24, 2009 at 3:14 PM, Guido van Rossum <guido@python.org> 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.
OK, I had misunderstood your earlier message. Sorry for the confusion.
No problem! I was probably using shorthand that only experienced devs understood. I hope you'll find other things to contribute! -- --Guido van Rossum (home page: http://www.python.org/~guido/)
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. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
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/)
Guido van Rossum wrote:
On Wed, Mar 25, 2009 at 5:46 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
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."
Even in hindsight, I think our reasons for providing a PEP 8 compliant threading API are sound. But the experience still makes me cautious of doing it again.
But we moved a bunch of other modules around too (urllib, http, db, I forget what else) and I think those worked out well.
For everything else, we just changed the module name or location. The test suite is pretty good at finding any relevant imports that need to be fixed, and 2to3 is also pretty good at handling them for third party code. The threading module was different in that we actually wanted to change the API of the module itself rather than just where to find it.
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.)
I think the main thing that may be putting me off is the amount of energy that went into deciding whether or not to emit Py3k warnings or DeprecationWarning or PendingDeprecationWarning for use of the old threading API. The difficulty of that decision strongly flavours my recollection of the whole process even though the final solution chosen was quite simple (maintain the two APIs in parallel, with a couple of notes in the documentation about the situation). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
Nick Coghlan wrote:
I think the main thing that may be putting me off is the amount of energy that went into deciding whether or not to emit Py3k warnings or DeprecationWarning or PendingDeprecationWarning for use of the old threading API.
Having made that decision, though, couldn't the result just be re-used for any future renaming exercises of this kind? -- Greg
Greg Ewing wrote:
Nick Coghlan wrote:
I think the main thing that may be putting me off is the amount of energy that went into deciding whether or not to emit Py3k warnings or DeprecationWarning or PendingDeprecationWarning for use of the old threading API.
Having made that decision, though, couldn't the result just be re-used for any future renaming exercises of this kind?
Maybe - the problem with taking that decision and trying to get a general rule out of it is that there were plenty of reasonable arguments on all sides (there were more than just 2 options, which made the choice all the more challenging). It wouldn't take many changes in the specifics of a situation for the "best" answer to be different from what we ended up doing in the threading case. The precedent would add weight to the idea of doing the same thing again, but I don't think it would be enough on its own to completely decide the matter. So the only general rule I really got out of that experience was actually "let's not do this again if we can possibly avoid it" :) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
On Thu, Mar 26, 2009 at 2:24 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Greg Ewing wrote:
Nick Coghlan wrote:
I think the main thing that may be putting me off is the amount of energy that went into deciding whether or not to emit Py3k warnings or DeprecationWarning or PendingDeprecationWarning for use of the old threading API.
Having made that decision, though, couldn't the result just be re-used for any future renaming exercises of this kind?
Maybe - the problem with taking that decision and trying to get a general rule out of it is that there were plenty of reasonable arguments on all sides (there were more than just 2 options, which made the choice all the more challenging). It wouldn't take many changes in the specifics of a situation for the "best" answer to be different from what we ended up doing in the threading case. The precedent would add weight to the idea of doing the same thing again, but I don't think it would be enough on its own to completely decide the matter.
So the only general rule I really got out of that experience was actually "let's not do this again if we can possibly avoid it" :)
I'll gladly take that as an added rationalization of my plea not to change datetime. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
I'll gladly take that as an added rationalization of my plea not to change datetime.
In the case of datetime, could perhaps just the module name be changed so that it's not the same as a name inside the module? Maybe call it date_time or date_and_time. -- Greg
On Thu, Mar 26, 2009 at 10:26 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Guido van Rossum wrote:
I'll gladly take that as an added rationalization of my plea not to change datetime.
In the case of datetime, could perhaps just the module name be changed so that it's not the same as a name inside the module? Maybe call it date_time or date_and_time.
I don't think that's advisable ATM -- again, something we should have done for 3.0, but now it's too late. I really don't want to set a trend where 3.1 is backwards incompatible with 3.0 *except* in cases where we were really planning to kill something in 3.0 and accidentally forgot to quite remove it completely (like cmp()). -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
On Thu, Mar 26, 2009 at 10:26 PM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Guido van Rossum wrote:
I'll gladly take that as an added rationalization of my plea not to change datetime. In the case of datetime, could perhaps just the module name be changed so that it's not the same as a name inside the module? Maybe call it date_time or date_and_time.
I don't think that's advisable ATM -- again, something we should have done for 3.0, but now it's too late.
I really don't want to set a trend where 3.1 is backwards incompatible with 3.0 *except* in cases where we were really planning to kill something in 3.0 and accidentally forgot to quite remove it completely (like cmp()).
Right. Otherwise pprint.pprint becomes pprint.p_print and ... That way madness lies. Besides which, what a terrific opportunity to castigate the Py3k developers forever. Opportunities like that don't come by every day ;-) regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ Want to know? Come to PyCon - soon! http://us.pycon.org/
participants (5)
-
Greg Ewing -
Guido van Rossum -
Jess Austin -
Nick Coghlan -
Steve Holden