Edward, The stc project was probably a Sisyphean task in the first place, esp as pointed out by Guido that to be useful it needs to do the hard parts well not just the easy parts on a restricted language subset. Any plan to apply the insights you've gained from studying the subject to creating a better semantic code browser/autocompleter for Python? Unlike the stc you can let the programmer deal with ambiguities in the case of autocompletion/code tips. By semantic I mean it is not just based on regex tag matching. I have not really used rope as I recall it may have performance issues? I use vim/cscope/pycscope combo to do code browsing for large code bases. It is very fast but unfortunately it is not complete and depends on tag matching that tends to produce too many answers or not enough at the same time. To see why, consider the following code snippet:
x = MyClass() y = x.my_method() The tag based approach will give you every method with the name my_method even though it is clear what you are looking for is MyClass.my_method. And it may not give you anything if you want to look up x (or give you all assignments to x whether in scope or not.) On Thursday, November 29, 2012 8:37:45 AM UTC-8, Edward K. Ream wrote: > > It's beginning to look as if the stc project will "succeed" in a different > way than I originally imagined :-) Indeed, it has been slowly dawning on > me that Python already *has* two superb type checkers. They are called > pylint and rope! That being so, the best way to move forward on the stc > project may be to encourage as many people as possible to flattr (or > otherwise contribute to) the developers of pylint and rope... > > I'm not sure how much more time I will devote to the stc project. This > post may form the basis for a "farewell" post on the stc group. But I'll > probably continue to work on the stc project long enough to answer > questions about how rope and pylint do what they do. Make no mistake, I am > still intensely curious about rope and pylint, perhaps more so now that I > have done so much studying without gaining real understanding. > > I might be a bit more embarrassed by these developments were it not that > Guido himself seems not to understood pylint and rope. Anyway, I have > enjoyed my work on stc. I have gained lots of experience with Python's > excellent (if slightly flawed) parser tools. The tricks in rope's ast.py > module are truly clever. I have been able to study TypeScript, a great > static analyzer for JavaScript. > > Most importantly, I have developed several tools and techniques for > analyzing other python programs. The most important technique is the dictum, > > "the only way to understand a computer program is to run it." > > This dictum has lead directly to several new tools: > > - An improved recursive import script in scripts.leo. This script now has > an option to create @edit nodes rather than @file nodes. While not as > clear as @file nodes, @edit nodes are a fast way of gaining access to files > for the purposes, say, of inserting calls to pdb.set_trace. > > - The g.SherlockTracer class. It's amusing to see how much simpler it is > to do in Python than in C. > > Having said all this, there is a sense of relief that I may soon be > working on Leo "full time". The list of good ideas worth doing seems > endless. Here are some likely improvements: > > 1. Integrate rope into Leo :-) I have spent the last two weeks studying > rope intensely. I may not understand rope's type inference mechanism > completely, but I do know that it works. More importantly, I have a great > deal of respect for rope's infrastructure; it provides what TypeScript > calls the "harness" that allows an editor to interact with rope, and vice > versa. Most of rope's code consists of this harness, and for good reason: > the nitty gritty details are inherently complex. > > I am convinced that it will be possible to drive rope from Leo. Indeed, > Leo's outline structure may make it possible to do some things to speed up > what looks like an inherently time-consuming type inference process. This > is not a one-day, or even one-week project. But it's worth doing. > > 2. More flexible unit testing. Leo needs better ways of managing unit > tests in external files, and of using custom subclasses of > unittest.TestCase. At present, the Leonine idiom that substitutes for > subclassing is:: > > exec(g.findTestScript(c,'@common <name of common code>')) > > This sorta works for all-Leo situations, but it won't work when test cases > are in separate files. I have some ideas for improvement, and some > mostly-failed experiments from the stc project. I expect some good things > to happen fairly soon. > > 3. There have been some interesting requests lately for improvements to > Leo. Two that come to mind are a) easier ways to execute scripts in a > separate process and b) a way to parameterize template nodes. I'd also > like easier ways to parameterize commands. I am sure that Leo's users will > continue to suggest improvements that I would never have imagined. > > So that's it. I expect a period of transition away from stc. It may take > weeks or even months, but I am eager to continue to improve Leo. > > Edward > > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To view this discussion on the web visit https://groups.google.com/d/msg/leo-editor/-/HNiLBpbTSKAJ. 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.
