> >> 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.