Debugging Python Extension Module

There's some useful technique for debugging Python extension module, gathered during these days work.

• Clewn is a way to combine VIM and GDB.
  
• Set break on PyErr_Format or PyErr_SetString so you can trace a Python exception raised from the extension module
• Use 'make EXTEA_CFLAGS="-ggdb3 -O0"' to compile Python so you can have debugging symbol in the compiled executable. (Thanks my mentor Richard told me that.)
  
• There is a Misc/gdbinit in Python's code base. It defined many useful macro for GDB. Put the file in your working directory and rename it to .gdbinit to use it. The most useful macro is "pyo", which prints many useful information of a PyObject.
• Valgrind is also a good debugging tool. (Btw, it has won the Trolltech Open Source Development Award recently.) There's a Misc/valgrind-python.supp for it.
• [Python-Dev] disappearing exceptions explained some odd behavior I've ever encountered. Seems even the print() statement also swallow exception. (At least in Python 3.0)

Anyway, happy hacking!

The test suite and disable 2to3 fixers

I'm writing SWIG makefile rules for testing today. Now I can see the test progress running well when I type "make check-python3-test-suite". It wonders me that so many tests can be passed! However, the failed tests should be the hardest part.

I have spend some time to work on Python 3's relative import, which mentioned on PEP 328, and PEP 366 seems a solution to my problem. But there is no 2to3 fixer to apply the PEP 366, so I had to disable the "import" fixer. The 2to3 has no option to disable a fixer now, so, this is how I did that:

$ 2to3 `2to3 -l | grep -v -E "Available|import$" | awk '{print "-f "$0}'` foo.py

This is the first time I tried to use awk, and the first time to write such a complicated command line. However, there should be a more clever way to do it.

The test suite still running, very slow, maybe due to that awful command line?