Re: [Python-ideas] Rename time module to "posixtime"

-1 to moving anything The situation is confusing and moving things will add to that confusion for a significant length of time. What I would instead suggest is improving the docs. If I could look in one place to find any time function it would mitigate the fact that they're implemented in multiple places. --- Bruce (via android) On Jun 16, 2010 12:56 AM, "M.-A. Lemburg" <mal@egenix.com> wrote: Brett Cannon wrote:
Please note that the time module provides access to low-level OS provided services which the datetime module does not expose. You cannot seriously expect that an application which happily uses the time module (only) for its limited date/time functionality to have to be rewritten just to stay compatible with Python. Note that not all applications are interested in sub-second accuracy and a computer without properly configured NTP and good internal clock doesn't even provide this accuracy to begin with (even if they happily pretend they do by exposing sub-second floats). You might want to do that for Python4 and then add all those time module functions using struct_time to the datetime module (returning datetime instances), but for Python3, we've had the stdlib reorg already. Renaming time -> posixtime falls into the same category. The only improvement I could see, would be to move calendar.timegm() to the time module, since that's where it belongs (keeping an alias in the calendar module, of course). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jun 16 2010)
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, ... Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ide...

On Wed, Jun 16, 2010 at 10:48 AM, Bruce Leban <bruce@leapyear.org> wrote:
-1 to moving anything
I am getting a feeling that you are attacking a strawman. Deprecating time module in favor of posixtime is only the third part of my proposal and I don't insist on any particular depreciation schedule. All I want is to give users one obvious way to avoid conflict between time and datetime.time. Note that since datetime only defines a handful of module level symbols, it is quite common to see from datetime import date, datetime, time and it is quite confusing when this conflicts with import time.
The situation is confusing and moving things will add to that confusion for a significant length of time.
Let's be constructive. What specifically do you find confusing? Do you agree with the list of confusing things that I listed in my previous posts?
I think having datetime.datetime.strftime and time.strftime documented in one place will not help anyone. And I am not even mentioning datetime.time.strftime which is of course not the same as time.strftime and that for {date,datetime,time}.strftime function you need to specify date/time object first and format last but for time module strftime it is the other way around. Etc. etc. I think most users will be happier not knowing about time module strftime function. Even better not knowing about strftime at all and using "..".format(dt) instead. And where in the docs would you explain the following: :-)
(Note utc in datetime calls and EST in time.strftime output.)

OK, let me revise that. There were lots of different things discussed on this thread. I agree that import time confounds with from datetime import time and it would be nice to fix that. An alias would be reasonable. Change the documentation to refer to the new name and leave the old name for legacy apps. I know TOOWTDI but if the time module has two names until python 4 is that a major problem? I'm not in favor of moving things around among the modules etc. When you say "And where in the docs would you explain the following: :-)" that sounds like you're saying "this is too confusing we shouldn't document it." To which I can only say :-( --- Bruce On Wed, Jun 16, 2010 at 8:25 AM, Alexander Belopolsky < alexander.belopolsky@gmail.com> wrote:

On Wed, Jun 16, 2010 at 10:48 AM, Bruce Leban <bruce@leapyear.org> wrote:
-1 to moving anything
I am getting a feeling that you are attacking a strawman. Deprecating time module in favor of posixtime is only the third part of my proposal and I don't insist on any particular depreciation schedule. All I want is to give users one obvious way to avoid conflict between time and datetime.time. Note that since datetime only defines a handful of module level symbols, it is quite common to see from datetime import date, datetime, time and it is quite confusing when this conflicts with import time.
The situation is confusing and moving things will add to that confusion for a significant length of time.
Let's be constructive. What specifically do you find confusing? Do you agree with the list of confusing things that I listed in my previous posts?
I think having datetime.datetime.strftime and time.strftime documented in one place will not help anyone. And I am not even mentioning datetime.time.strftime which is of course not the same as time.strftime and that for {date,datetime,time}.strftime function you need to specify date/time object first and format last but for time module strftime it is the other way around. Etc. etc. I think most users will be happier not knowing about time module strftime function. Even better not knowing about strftime at all and using "..".format(dt) instead. And where in the docs would you explain the following: :-)
(Note utc in datetime calls and EST in time.strftime output.)

OK, let me revise that. There were lots of different things discussed on this thread. I agree that import time confounds with from datetime import time and it would be nice to fix that. An alias would be reasonable. Change the documentation to refer to the new name and leave the old name for legacy apps. I know TOOWTDI but if the time module has two names until python 4 is that a major problem? I'm not in favor of moving things around among the modules etc. When you say "And where in the docs would you explain the following: :-)" that sounds like you're saying "this is too confusing we shouldn't document it." To which I can only say :-( --- Bruce On Wed, Jun 16, 2010 at 8:25 AM, Alexander Belopolsky < alexander.belopolsky@gmail.com> wrote:
participants (2)
-
Alexander Belopolsky
-
Bruce Leban