[Python-Dev] RE: [Patches] selfnanny.py: checking for "self" in every method

Tim Peters tim_one@email.msn.com
Sat, 4 Mar 2000 21:22:16 -0500


[Guido van Rossum]
> Before we all start writing nannies and checkers, how about a standard
> API design first?  I will want to call various nannies from a "Check"
> command that I plan to add to IDLE.  I already did this with tabnanny,
> and found that it's barely possible -- it's really written to run like
> a script.

I like Moshe's suggestion fine, except with an abstract base class named
Nanny with a virtual method named check_ast.  Nannies should (of course)
derive from that.

> Since parsing is expensive, we probably want to share the parse tree.

What parse tree?  Python's parser module produces an AST not nearly "A
enough" for reasonably productive nanny writing.  GregS & BillT have
improved on that, but it's not in the std distrib.  Other "problems" include
the lack of original source lines in the trees, and lack of column-number
info.

Note that by the time Python has produced a parse tree, all evidence of the
very thing tabnanny is looking for has been removed.  That's why she used
the tokenize module to begin with.

God knows tokenize is too funky to use too when life gets harder (check out
checkappend.py's tokeneater state machine for a preliminary taste of that).

So the *only* solution is to adopt Christian's Stackless so I can rewrite
tokenize as a coroutine like God intended <wink>.

Seriously, I don't know of anything that produces a reasonably usable (for
nannies) parse tree now, except via modifying a Python grammar for use with
John Aycock's SPARK; the latter also comes with very pleasant & powerful
tree pattern-matching abilities.  But it's probably too slow for everyday
"just folks" use.  Grabbing the GregS/BillT enhancement is probably the most
practical thing we could build on right now (but tabnanny will have to
remain a special case).

unsure-about-the-state-of-simpleparse-on-mxtexttools-for-this-ly y'rs  - tim