the Gravity of Python 2
Roy Smith
roy at panix.com
Wed Jan 8 20:27:30 EST 2014
In article <laknps$umv$1 at dont-email.me>,
Kevin Walzer <kw at codebykevin.com> wrote:
> I haven't updated my Python apps to 3.x because there's nothing in 3.x
> that offers benefits to my users.
I almost found a reason to move to Python 3 today. Then I got smacked.
I had a datetime. I needed a unix timestamp. People need to go back
and forth between these two things all the time and in Python 2 it's the
very definition of impedance mismatch. What should be a dead simple
operation involves long threads on stackoverflow discussing which of
several amalgamations of duct tape is the least ugly.
Anyway, I discovered that Python 3.3's datetime has a .timestamp()
method. Yeah. Finally. Exactly what the world had needed for years.
Then I kept reading and found:
Note: There is no method to obtain the POSIX timestamp directly from a
naive datetime instance representing UTC time.
Ugh. So, we're back to square one. They go on to suggest one of two
workarounds, either calling datetime.replace() to insert a timezone, or
subtracting from the epoch manually.
Naive datetimes are what everybody uses. It's what utcnow() gives you.
So why make life difficult for everybody? Python 3 didn't win a convert
today.
More information about the Python-list
mailing list