Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
Guido van Rossum wrote: On Thu, Mar 26, 2009 at 10:26 PM, Greg Ewing greg.ew...@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/ ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
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 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
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 | ncogh...@gmail.com | Brisbane, Australia --- ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
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 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
On Thu, Mar 26, 2009 at 10:26 PM, Greg Ewing greg.ew...@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/) ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
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 | ncogh...@gmail.com | Brisbane, Australia --- ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
On Wed, Mar 25, 2009 at 5:46 AM, Nick Coghlan ncogh...@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/) ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
Guido van Rossum wrote: On Wed, Mar 25, 2009 at 5:46 AM, Nick Coghlan ncogh...@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 | ncogh...@gmail.com | Brisbane, Australia --- ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
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 jaus...@post.harvard.edu wrote: On Tue, Mar 3 at 19:25:21 Guido van Rossum gu...@python.org wrote: On Tue, Mar 3, 2009 at 5:15 PM, Brett Cannon br...@python.org wrote: On Tue, Mar 3, 2009 at 05:13, rdmur...@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/) ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
On Tue, Mar 24, 2009 at 1:23 PM, Jess Austin jaus...@post.harvard.edu wrote: On Tue, Mar 24, 2009 at 3:14 PM, Guido van Rossum gu...@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/) ___ 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/archive%40mail-archive.com
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 gu...@python.org wrote: On Tue, Mar 3, 2009 at 5:15 PM, Brett Cannon br...@python.org wrote: On Tue, Mar 3, 2009 at 05:13, rdmur...@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/archive%40mail-archive.com
Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
Benjamin Peterson wrote: Yes, I'm already looking forward to Py4k now. :) Shh, Guido will need at least 5 years before he's ready to contemplate going through something like this again. Or maybe a decade to be on the safe side ;) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
On Wed, Mar 4, 2009 at 3:23 AM, Nick Coghlan ncogh...@gmail.com wrote: Benjamin Peterson wrote: Yes, I'm already looking forward to Py4k now. :) Shh, Guido will need at least 5 years before he's ready to contemplate going through something like this again. Or maybe a decade to be on the safe side ;) Actually Py4k will have to be on the next BDFL's watch. :) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
2009/3/4 Guido van Rossum gu...@python.org: On Wed, Mar 4, 2009 at 3:23 AM, Nick Coghlan ncogh...@gmail.com wrote: Benjamin Peterson wrote: Yes, I'm already looking forward to Py4k now. :) Shh, Guido will need at least 5 years before he's ready to contemplate going through something like this again. Or maybe a decade to be on the safe side ;) Actually Py4k will have to be on the next BDFL's watch. :) Somebody warn Orlijn now!!! :-) Paul. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
On Tue, Mar 3, 2009 at 05:13, rdmur...@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. 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? As a user I'd be +1 on that. In fact, I might even start using 'as' in my own code for that purpose right now. I've always felt vaguely confused and disturbed whenever I imported 'datetime', but until this discussion I didn't realize why :) Thinking about it, I know I've written 'from datetime import DateTime' a number of times and then had to go back and fix my code when I tried to run it. And I'm sure that sometimes when that happens I've had to (re)read the docs (or do a 'dir') to find out why my import wasn't working. Having said all that out loud, I think I might be stronger than a +1 on this idea. I'd be willing to help with doc and even code patches once I finish learning how to contribute properly. +1 from me to fix these little mishaps in naming in both modules. -Brett ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
On Tue, Mar 3, 2009 at 5:15 PM, Brett Cannon br...@python.org wrote: On Tue, Mar 3, 2009 at 05:13, rdmur...@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. As a user I'd be +1 on that. In fact, I might even start using 'as' in my own code for that purpose right now. I've always felt vaguely confused and disturbed whenever I imported 'datetime', but until this discussion I didn't realize why :) Thinking about it, I know I've written 'from datetime import DateTime' a number of times and then had to go back and fix my code when I tried to run it. And I'm sure that sometimes when that happens I've had to (re)read the docs (or do a 'dir') to find out why my import wasn't working. Having said all that out loud, I think I might be stronger than a +1 on this idea. I'd be willing to help with doc and even code patches once I finish learning how to contribute properly. +1 from me to fix these little mishaps in naming in both modules. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
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 think the old names basically have to live forever in some way, due to loading old pickles. Remember the problems we had when we tried to restructure the library in 2.6? ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
On Tue, Mar 3, 2009 at 17:30, Eric Smith e...@trueblade.com wrote: 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 think the old names basically have to live forever in some way, due to loading old pickles. Remember the problems we had when we tried to restructure the library in 2.6? Forever is a long time. =) If we keep the PendingDeprecationWarning for a long time and really get the word out of the renames then people can migrate their pickles over time. The real problem with the 2.6 reorg was that people didn't want to have zero lead time to update their pickles and they way the transition was being handled. In this case the old names and simply subclass the new names and have no issues with old code. -Brett ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
Brett Cannon wrote: On Tue, Mar 3, 2009 at 17:30, Eric Smith e...@trueblade.com mailto:e...@trueblade.com wrote: 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 think the old names basically have to live forever in some way, due to loading old pickles. Remember the problems we had when we tried to restructure the library in 2.6? Forever is a long time. =) If we keep the PendingDeprecationWarning for a long time and really get the word out of the renames then people can migrate their pickles over time. The real problem with the 2.6 reorg was that people didn't want to have zero lead time to update their pickles and they way the transition was being handled. In this case the old names and simply subclass the new names and have no issues with old code. There's also no reason why someone couldn't write a pickle updater for when such problems do rear their ugly heads. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Adding PEP consistent aliases for names that don't currently conform
2009/3/3 Brett Cannon br...@python.org: On Tue, Mar 3, 2009 at 17:30, Eric Smith e...@trueblade.com wrote: 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 think the old names basically have to live forever in some way, due to loading old pickles. Remember the problems we had when we tried to restructure the library in 2.6? Forever is a long time. =) If we keep the PendingDeprecationWarning for a long time and really get the word out of the renames then people can migrate their pickles over time. The real problem with the 2.6 reorg was that people didn't want to have zero lead time to update their pickles and they way the transition was being handled. In this case the old names and simply subclass the new names and have no issues with old code. Yes, I'm already looking forward to Py4k now. :) -- Regards, Benjamin ___ 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/archive%40mail-archive.com
