On Nov 16, 1:06 pm, "Edward K. Ream" <[email protected]> wrote:
> In short, we are *very* close to having a fully functional leoInspect module.
Rev 4815 demonstrates that the project is *already* a complete
success. I never would have dreamed that one day would have seen so
much progress.
This is a longish post, but it will be worth reading if you are at all
interested in the leoInspect project.
Here is a unit test that demonstrates that the assignments() getter
works::
import leo.core.leoInspect as inspect
m = inspect.module(c,'leoEditCommands.py')
for z in m.assignments():
print(z)
print(z.tree())
print(z.sd.dump_ast(z.tree()))
break
And here is the output::
statement(assn)
<_ast.Assign object at 0x04395E10>
Assign
targets=[...
Name
id='enchant'
ctx=Store
value=Name
id='None'
ctx=Load
----------------------------------------------------------------------
Ran 1 test in 0.539s
This demonstrates *all* the essentials of the leoInspect module. In
particular, this trace shows that the still-unwritten format method
will have the proper AST to work with. In other words, all the data
exists!
When the format method is written, we would replace::
print(z.sd.dump_ast(z.tree()))
by:
print(z.format())
but that is just "syntactic sugar". And rather than printing the
"raw" AST tree shown above, format will print it as it would look in
the actual source file. It will take a bit of work tomorrow...
Imo, this one day's work has justified the work I have done on the
various lint over the last several years.
A huge change in perspective
======================
Besides the actual code, something even more important has happened
today. Actually, two, no *three* somethings.
1. The leoInspect module has suddenly become completely easy to
understand. It's has become an utterly vanilla AST traversal,
combined with straightforward data classes.
2. More importantly, I now see the leoInspect module in a whole new
light. Indeed, leoInspect is the *static, passive* component of the
inspection process. The Leo scripts that use the leoInspect module
are the *active, creative, dynamic* part of the inspection process.
It is this separation between active and passive components that has
utterly collapsed the complexity of leoInspect.
3. Finally, the separation of active and passive parts means that
leoInspect now becomes an *excellent* foundation for yet another
version of LeoLint. What an irony: by giving up the attempt to do a
full-fledged lint we have suddenly been "gifted" with a superb
platform for further lint work. Astounding.
Edward
P.S. Let me brag just a bit more. All the getters now take an "all"
keyword argument. If True, the getters recursively discover the
desired information in the given object and all subsidiary objects.
All the getters have a simple pattern. Here is the assignments()
getter: the others are virtually the same code, with straightforward
modifications:::
def assignments (self,all=True):
if all:
return self.all_assignments(result=None)
else:
return self.filter_assignments(self._statements)
def all_assignments(self,result):
if result is None:
result = []
result.extend(self.filter_assignments(self._statements))
for aList in (self._classes,self._defs):
for cx in aList:
cx.all_assignments(result)
return result
def filter_assignments(self,aList):
return [z for z in aList
if z.kind in ('assn','aug-assn')]
The trunk contains unit tests for all the completed getters. In fact,
creating the unit tests was an integral part of development: the tests
greatly *increased* coding and testing speed.
Quite a day's work. It started about 3:30 a.m, and now it's about
8:30 p.m.
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.
