On Mar 2, 8:49 am, "Edward K. Ream" <[email protected]> wrote:
> The significant problem: the pep8 fixer might want to munge ivars and > module-level vars and constants. To do this, the code must know the > text range of classes, functions and methods. Happily, this can be > done in a very fast prepass. Here is the rough design: Done at rev 25. There are a few unexpected complications: 1. We had best discover the context ranges after doing all local munges. This required a bit of refactoring. 2. We don't have to worry about context ranges moving during the global pass, because the global changes happen in a results array. The contents of files_dict don't get updated until after the pass. In general though, any changes will change context. That's true regardless of how we represent the program: as text, as tokens or as ast's. 3. Rev 25 creates a dict containing one context dict per file. However, this design is dubious, because it's not clear how to discover which ranges "cover" a particular text offset. So instead of doing a prepass before pass 2 to create global context *dicts*, it would seem more clever just to maintain a context stack *during* pass 2. To discover the context we just look at the context stack as it exists as we are scanning. This is the simplest thing that could possibly work. We can do this over and over again in as many passes as we like: the cost to discover context is nothing. To summarize, there are two, no three, essential features of pep8.py: 1. A multi-pass organization. This simplifies the overall organization, and simplifies the various munges as well. As I have just discussed, we can "recreate" context in each pass essentially for free. As another example, each pass must therefor repeatedly init the per-file settings. Again, this "duplication" carries no real cost. 2. A text orientation. We are dealing with text. It does not help to pretend we aren't. Python's syntactic simplicity makes this counter- intuitive approach possible. 3. A focus on semantics, not syntax. This is likely to be the big one in the context of a new pylint. It's easy to get mesmerized by syntax, but deductions require data that has nothing to do with syntax. 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.
