Today was part coding, part reading/thinking. The coding part was continuing to try to get it so that various tests in the test suite didn't reset the trace function set by coverage tools (this is being tracked in issue #10990). Turns out that there are typically two reasons why a test resets the trace function: it does it on purpose or forces a recursion depth RuntimeError. The former issues simply need to play nice and not wipe out the trace function blindly (as well as not run on VMs other than CPython since it's an implementation detail). The latter occurs because running up against the recursion limit usually ends up triggering the RuntimeError in the trace function, which causes the function to be removed under the assumption its buggy. Unless some fancy redesign of these semantics is developed the tests will simply need to have some guard that either unsets the trace functions temporarily or simply skips the test.
In terms of reading/thinking, I am trying to decide how I want to structure my Python 2->3 porting guide. My current thinking breaks down into three possible options for people. One, if you are creating a new project and your dependencies have already ported to Python 3, then write your project in Python 3 as well and use 3to2. If you have pre-existing Python 2 code and want to maintain a separate Python 3 codebase, use 2to3 to create a Python 3 branch of your code. Otherwise make your code source-compatible between Python 2 and 3 with the help of six.
