> > ??? EPOCH is not even a constant in the datetime module.
> >
> No, and it does not belong there.

And so what was your point exactly?

> A higher level library that uses
> seconds since epoch for interchange

I don't think the "time" module can be named "higher level", and it
still handles such timestamps.

> datetime(1970, 1, 1) + timedelta(seconds=s)
> 
> is obvious, self-contained,  short and does not require any knowledge
> other than elementary school arithmetic to understand.

Sigh.
Again: it's so obvious that you're the only one who seems to easily come
up with those solutions. How many times does it have to be repeated?

> Compared to
> this, "utcfromtimestamp" is a monstrosity that suggests that something
> non-trivial, such as UTC leap seconds is been taken care of.

I don't see anything suggesting it is a monstrosity. The name is
grammatically bizarre, but that's all.

> Let's see:
> [snip]
>
> which one is *obviously* correct?  Are they *obviously* equivalent?

Both are obviously correct for whatever the non-perverted user has in
mind. People in real life don't care whether they will retain
microsecond precision when carrying a floating point timestamp around.
For the simple reason that the data source itself will not have such
precision.

> Note that when timedelta.total_seconds() was first committed, it
> contained a numerical bug.  See issue8644.

So? What is your point?

> In any case, you ignore the hard question about totimestamp():
> fromtimestamp() is not invertible in most real life timezones.  If you
> have a solution that does not restrict totimestamp() to UTC, I would
> like to hear it.

IMO, the solution would have the datetime object carry the offset from
UTC with it, rather than try to be smart and compute it dynamically.