Imo, we have been discussing various workarounds to not having this tool.
This post will be pre-writing for documentation and/or the docstring.
leoAst.py will contain a new class, *PatternMatchingFormatter*, a subclass
of AstFormatter. Lets call this class *pmf *for short.
The pmf class is intended to be the *ultimate* prototyping tool. I hope to
have something to show in a few hours.
Here are the components of the Eureka:
My original idea was to have each visitor return it's result only if
match(node) returns. But it's much easier to have the pmf.visit method
"filter" the result! So simple, so powerful. No AstFormatter node visitors
will probably change!
The default pmf.match method will always return True, but in a slow/general
way that supports easy extension. Subclasses may override pmf.match for
more control.
Here are the component Aha's:
*Aha 1*: The pmf class will define an empty list of ast classes that will
always match. Subclasses may redefine this list. For example: match_all =
[ast.ClassDef, ast.FunctionDef]
*Aha 2*: The pmf class will define an empty list of *regex patterns* to be
applied to all or some nodes. Subclasses may redefine this list. The list
will consist of tuples:
match_regex = [
(None, regex), # Apply regex to all nodes.
(ast.Expr, regex), # Apply regex only to ast.Expr nodes.
((ast.ClassDef, ast.FunctionDef), regex), # Apply regex only to two
kinds of nodes.
]
*Aha 3*: pmf.visit will support full context handling, as in
AstFullTraverser. This allows prototypes to handle nested contexts in a
completely rigorous manner, as they like.
*Aha 4*: pmf.visit will allow subclasses to define *on_match* methods to be
called when a match succeeds. For example, on_match_FunctionDef,
on_match_Call, etc.
pmf.visit(node) will call these methods using
getattr('on_match_'+node.__class__.__name__, None).
pmf.visit will call on_match methods *in addition to* calling the regular
node visitors. This will allow additional semantic processing to be done
(with full context available), without having to override visitors. *This
is a new pattern for me*, which I started to understood only while writing
this post. It may be possible to do even more cool things...
*Aha 5*: As I write this, I see that pmf class will likely only need to
override the AstFormatter.visit method! For the ultimate in control,
subclasses could override pmf.visit.
*Summary*
The idea of the PatternMatchingFormatter class is a true Eureka. It could
have formed the basis of the check-conventions project. I plan to recast
the check-conventions code to use this code.
It should be possible to create pmf.visit and its helpers in an hour! We
shall see...
This Eureka was "primed" by the thought that we need slower, more general
tools :-)
Edward
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
