Whew.  Last night, I finally nailed the bug that forced me to get lost inside Python.  Debugging Python inside Internet Explorer is not easy.  To debug native code inside Python, I had to rebuild all of Python, Pythonwin, and PyWin32 native code because you have to have debug builds of all the DLLs.  To debug Python scripts, I wrote some debugging helper code that lets me watch each line of Python code executing.  I am going to hook up a real Python debugger as an IE explorer bar (like the Favorites bar) so I can step through Python scripts and set debug points.  That would be so cool!

Finding out that win32ui module required hosting application to be written in MFC stumped me because I was hosting Python as a DLL written in ATL/WTL and IE doesn't seem to be written in MFC.  Come to think of it, its been ages since I last wrote an MFC application.  I think the last one was NetDynamics Studio.  NetDynamics was bought by Sun and NetDynamics products turned into iPlanet and I have no idea if they are still using the code I wrote.  I was going to replace it with a XUL-engine written Java, but that never happened.

Coercing Win32com module to use existing IE automation objects took some effort, mostly spent on trying to figure out how Win32com works.  I had to patch win32com.client.dynamic.py to do what I needed to.  Real bummer was finding out that most of Win32com is written in Python.  This means its much slower than native glue code.  For most COM automation use, this is no problem since tasks performed by each COM method takes much longer than the time it takes to invoke the method via Python-based Win32com code.  But for manipulating IE DOM, this is dog slow.  Sometimes, I can literally see changes being made to a web page.  Also, each COM dispatch object uses too much memory in Win32com.  Just touching all the nodes in a document will be prohibitive.

I'll have to write my own optimized COM glue for Python at some point.  For now, I am pushing forward with Win32com.