Just the kind of stuff I like, looking forward to being able to try it without having to understand how it works :-]
Probably off topic, but I'm reminded of my reaction to lots of testing tools, especially the coverage stuff which produces listings of execution paths. The intent of the listing is to determine which lines of code are tested, but that's not what I see. When I see that, I don't think of testing, I think "what a wonderful, automatically generated, explanation of how the pieces of the app work together, and what the control flow looks like" I think the one I've seen is Figleaf, found here http://pycheesecake.org/wiki/PythonTestingToolsTaxonomy Thanks, Kent On Wed, Nov 16, 2011 at 5:01 AM, Edward K. Ream <[email protected]> wrote: > I'd like a module, call it leoInspect, which would, in effect, provide > answers to questions about Leo's source code such as: > > - Where are all assignments to 'w' in leoEditCommands.py? > > - Which of those assignments are "unusual" or "suspect" (in ways to be > specified)? > > This is, in essence, a re-imagining of the new-pylint project, which > has been a "hobby" project of mine for several years. Rather than > attempting global "proofs" of difficult propositions, as in new- > pylint, the leoInspect module answer specific pattern-oriented > questions about specific files. We could use such answers while > debugging, or as documentation, or especially as the foundation for > *fast* unit tests. > > My first thought was that the simplest thing that could possibly work > would be a souped-up search command. As a quick prototype, yesterday I > wrote a short script, based on a simple Python tokenizer, that would > find non-comment, non-string lines containing assignments. > > Suppose we are interested, for whatever reason, in assignments to "i". > Such a script, when run on itself, yields assignments to "i" like:: > > result,i,line_number=[],0,0 > kind,i= "S",i+1 > i+= 1 > kind,i= "S",g.skip_to_end_of_line(s,i) > > This illustrates the pitfalls of text-based approaches. Finding the > "real" assignments to "i" will be ugly. In retrospect, this is hardly > surprising. An approach based on AST trees will be cleaner and more > flexible in the long run. > > The AST traversal code in new-pylint will form the foundation of > leoInspect. Traversals creates semantic data (symbol tables, etc.) > that will also be useful in leoInspect. > > As I write this, I see that the problem is to create a "query > language" that can be translated into specific AST traversals. By > "query language" I mean any mechanism that could produce specific > searches. API might be a better word for what I imagine. In any > case, creating queries of AST trees creates a new world of > invention... > > Happily, speed is *not* a big problem. The kind of queries I envisage > can certainly be done in time proportional to O(N) where N is the size > of the code being examined. More sophisticated queries might require > multiple passes over the tree (or data structures built from the tree) > but that's still O(N). I expect most queries to take less than a > second, even on Leo's largest source files. For example, new-lint > takes 1.5 seconds to create AST trees for *all* of Leo's sources, and > another 2 seconds to traverse all the trees. > > Your comments please, Amigos. > > 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. > > -- 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.
