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