This is very interesting work - thank you!

Sorry for not commenting earlier (very busy), so here are my thoughts so far.

The baseline for the diff appears to be against the py3k branch, in that it adds back in classes from 2.*: PyIntObject.

There's currently some deliberate divergence between the code in the 2.7 branch and the py3k branch.  For example, in the 2.7 branch, we pretty-print PyUnicodeObject instances with a u'' prefix, whereas in the py3k branch we pretty-print them plainly: the code is trying to mimic the underlying syntax of a particular version of the python language in the inferior process.  (In both cases though, the gdb code is for python 2)

Are you attempting to support both python 2 and python 3 (in the inferior process) from the same code?

Going through the individual parts of the patch:

Do the changes to "pretty_printer_lookup" slow things down, I wonder?  (It has to be called every time gdb print a pointer)

"py-globals" looks like a nice addition, though I feel there should be an abstract base class for PyLocals and PyGlobals to inherit from ("PyNamespaceCommand", perhaps, though that sucks as a name).

The "py-break" command looks very useful  Unfortunately, AIUI we're in feature freeze for 3.2 now (sorry not to get to this earlier), and I have some fears about compatibility with all of the different versions of gdb 7 that are out there.  What versions of gdb have you tested this with?

_LoggingState looks interesting; getting the various versions of gdb to capture output as a python string can be challenging.  In particular, I've run into problems with buffering of large amounts of output; see: https://bugzilla.redhat.com/show_bug.cgi?id=620930

get_selected_inferior() clearly is impacted by gdb bugs, so I'm warying about merging that
Likewise for GenericCodeStepper.init_breakpoints (probably should refrain from swearing in comments, if nothing else, it's a dead give away that the code needs more work :)  I don't know if we have any rules about it, but I don't remember seeing such "colorful" language before in python's sources)

I notice that the selftests use skip_unless_7_2_decorator on the tests for py-break, py-step, py-next and py-exec.  If these commands only work on a sufficiently recent version of gdb, should the commands themselves also be wrapped in a conditional?   Either not registering them if gdb doesn't have the support, or perhaps registering a fallback that says "gdb not recent enough", or somesuch.  Part of gdb's UI is tab-completion, and it's nice for "py-[TAB]" to present all useful options.  That makes me think that we shouldn't register commands that are known to be incompatible with the running gdb version.

This is exciting work, in that gdb seems to be getting significantly more powerful, and the debug hooks are advancing to take advantage of it.  Unfortunately, given that Tools/gdb/libpython.py is part of the python source tree, it's arguably governed by the same feature freeze rules as the rest of Python (e.g. no new features in 2.7).  I wonder if an exception can be made for it, given that this code is a support tool that runs in a different process to the main python build, potentially for a different major-release of python.   (At some point we'll want to port gdb to python 3, which I'm not looking forward to...)