> Maybe this is a dead and buried subject, but I'm going to try anyway, since
> everyone's been in such a wonderful 'lets fix ugly but harmless nits' mood
> lately :)
>
> Why do we need the following atrocity <wink>:
>
> timestr = time.strftime("<format>", time.localtime(time.time()))
>
> To do the simple task of 'date +<format>' ? I never really understood why
> there isn't a way to get a timetuple directly from C, rather than converting
> a float that we got from C a bytecode before, even though the higher level
> almost always deals with timetuples. How about making the float-to-tuple
> functions (time.localtime, time.gmtime) accept 0 arguments as well, and
> defaulting to time.time() in that case ? Even better, how about doing the
> same for the other functions, too ? (where it makes sense, of course :)
>
> Actually, I'll split it up in three proposals:
>
> - Making the time in time.strftime default to 'now', so that the above
> becomes the ever so slightly confusing:
>
> timestr = time.strftime("<format>")
> (confusing because it looks a bit like a regexp constructor...)
I don't see the confusion.
> - Making the time in time.asctime and time.ctime optional, defaulting to
> 'now', so you can just call 'time.ctime()' without having to pass
> time.time() (which are about half the calls in my own code :)
>
> - Making the time in time.localtime and time.gmtime default to 'now'.
>
> I'm 0/+1/+1 myself :)
Yes, I've wondered this myself too. I guess the current API is based
too much on the C API...
+1/+1/+1.
--Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4