Antoine Pitrou <pit...@free.fr> added the comment: > >> 1. Different application may need different epoch and retained > >> precision depends on the choice of the epoch. > > > > But then why does fromtimestamp() exist? > > A better question is why datetime.utcfromtimestamp(s) exists given > that it is actually longer than equivalent EPOCH + timedelta(0, s)?
??? EPOCH is not even a constant in the datetime module. And regardless, the point is *not* the number of characters typed, but how easy it is to come up with the solution. Calling the appropriate (and appropriately-named) method is much easier than coming up with the right datetime arithmetic incantation. It's Python, not Perl. "There should be one obvious way to do it". > > And returning a (seconds, microseconds) tuple does retain the precision. > > > > It does, but it does not help much those who want a float - they would > still need another line of code. Yes, but a very obvious one at least. > Note that with divmod(timedelta, > timedelta), you can now easily extract (seconds, microseconds) or > any other tuple like (weeks, days, seconds. microseconds) from > timedelta objects. Do you think many users even think of calling divmod() timedelta objects? I don't, personally. You apparently hold the opinion that the datetime module should be reserved for experts in arithmetic over dates, times and timedeltas. But it's not. It's the Python stdlib and it should provide reasonably high-level tools to do the job. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue2736> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
