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?
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.
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: :-)
from datetime import datetime import time time.strftime("%c %z %Z", datetime.utcnow().utctimetuple()) 'Wed Jun 16 15:22:15 2010 -0500 EST'
(Note utc in datetime calls and EST in time.strftime output.)