The last several days have produced some unexpected Ahas, and have yielded a plan for a major new project. This project is something I've always wanted to do, and it will benefit Leo.
===== Motivation The genesis of the plan lies in the observation that type inference keeps cropping up in unexpected places. Indeed, sitting in the bathtub a few days ago I realized that essentially any kind of refactoring in Python requires type inference. Without it, it's not possible to rename members of classes that might be referenced outside the class definition itself. Leo has lots of such variables. For example, all members of the chain c.frame.body.bodyCtrl.widget. Sure enough, when I looked at the source code for rope, http://rope.sourceforge.net/, I saw type inference machinery that rivals that found in pylint. Recall that yesterday I said that epydoc appears to use type inference, but it's a fake: it simply shows a guess of the type on roll-over, but produces a (buggy) dialog requiring the user to know the type. ===== The plan I want to study at least the following packages: coverage, 2to3, pylint and rope, with the goal of understanding them at least as well as their authors do. This is an ambitious plan. pylint and rope in particular use elegant tree traversals of AST trees in order to deduce type information. The elegance of the traversals actually makes the task of understanding harder, imo. coverage and 2to3 also traverse AST trees, but for completely different purposes. I need "deep" understanding of these products in order to truly understand the choices their designers made. At a certain point, which I have already reached, re-reading the code provides little new insight. After that point, one must actually run the programs to understand more fully how they work. So an alternate statement of the plan is to create a framework for understanding python programs in detail. I plan to do this by creating a **tracing debugger**, tdb, based, of course, on pdb. As you may know, I have some experience doing this kind of thing. In order to find a nasty pylint bug, I created a small subclass of pdb that stopped executing when the stack had reached 200 levels deep. (I chose 200 by a process of trial and error.) This allowed me to catch a truly complex stack overflow bug as early as possible. ===== Schedule At this point, it's not entirely clear what tdb will do, except that it will gather whatever information and print whatever traces that I want. It may take days, weeks or months of experimentation before I can discover exactly what makes each program tick. This is the kind of puzzle I truly enjoy. More importantly, the programs that I shall be studying are some of the most important tools in the Python world. I think it would help the Python community to be able to tell people exactly how and why they work. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
