I should mention that just because these tests pass does not mean the Py3 support is in good shape.

On the contrary, it is really bad.

For example:

• Almost all of the strings are still 'val' without declaring bytestring (Py2) or unicode (Py3). Hence they are a different type from one to the other.
• The convenience method of casting to a string str(e) or '%s' % val is used without an idea of what the value actually is. In Py3, str(b'a') == "b'a'". It's very clear just from the changes I had to make that the most parts of the code assume Python2 strings.

Also, it seems to me that one of the reasons the tests seem slow is file I/O. There is a nontrivial amount of reading from the DATA_DIR which could be replaced with a module containing the actual content. I somewhat understand wanting tests to actually make sure that file I/O is working, but it is so low-level it isn't really necessary to test (though open(filename) with no mode actually happens in this library 😢).

I don't think the people who gave Python3 support read this:
https://docs.python.org/3/howto/pyporting.html

yeah, i'm sure there's a lot to be done for better py3 support. the current support does seem to be much better than what we had before (i.e. none at all ;)).

@craigcitro I am legitimately concerned with the quality of the code, not just "ew this is gross" but actual places where no one is clear on the behavior. Just my two cents.