OK, let me revise that. There were lots of different things discussed on this thread. I agree that<div><br></div><div>    import time</div><div>confounds with </div><div>    from datetime import time</div><div><br></div><div>


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?</div>


<div><br></div><div>I'm not in favor of moving things around among the modules etc.</div><div><br></div><div>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 :-( </div>


<div><br clear="all">--- Bruce<br>
<br><br><div class="gmail_quote">On Wed, Jun 16, 2010 at 8:25 AM, Alexander Belopolsky <span dir="ltr"><<a href="mailto:alexander.belopolsky@gmail.com" target="_blank">alexander.belopolsky@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Jun 16, 2010 at 10:48 AM, Bruce Leban <<a href="mailto:bruce@leapyear.org" target="_blank">bruce@leapyear.org</a>> wrote:<br>
> -1 to moving anything<br>
><br>
<br>
I am getting a feeling that you are attacking a strawman.  Deprecating<br>
time module in favor of posixtime is only the third part of my<br>
proposal and I don't insist on any particular depreciation schedule.<br>
All I want is to give users one obvious way to avoid conflict between<br>
time and datetime.time.  Note that since datetime only defines a<br>
handful of module level symbols, it is quite common to see from<br>
datetime import date, datetime, time and it is quite confusing when<br>
this conflicts with import time.<br>
<div><br>
> The situation is confusing and moving things will add to that confusion for<br>
> a significant length of time.<br>
><br>
</div>Let's be constructive.  What specifically do you find confusing?  Do<br>
you agree with the list of confusing things that I listed in my<br>
previous posts?<br>
<div><br>
> What I would instead suggest is improving the docs. If I could look in one<br>
> place to find any time function it would mitigate the fact that they're<br>
> implemented in multiple places.<br>
<br>
</div>I think having datetime.datetime.strftime and time.strftime documented<br>
in one place will not help anyone.  And I am not even mentioning<br>
datetime.time.strftime which is of course not the same as<br>
time.strftime and that for {date,datetime,time}.strftime function you<br>
need to specify date/time object first and format last but for time<br>
module strftime it is the other way around. Etc. etc.<br>
<br>
I think most users will be happier not knowing about time module<br>
strftime function.  Even better not knowing about strftime at all and<br>
using "..".format(dt) instead.<br>
<br>
And where in the docs would you explain the following: :-)<br>
<br>
>>> from datetime import datetime<br>
>>> import time<br>
>>> time.strftime("%c %z %Z", datetime.utcnow().utctimetuple())<br>
'Wed Jun 16 15:22:15 2010 -0500 EST'<br>
<br>
(Note utc in datetime calls and EST in time.strftime output.)<br>
</blockquote></div><br></div>