On Sat, 4 Mar 2000, Guido van Rossum wrote: > Before we all start writing nannies and checkers, how about a standard > API design first? I thoroughly agree -- we should have a standard API. I tried to write selfnanny so it could be callable from any API possible (e.g., it can take either a file, a string, an ast or a tuple representation) > I will want to call various nannies from a "Check" > command that I plan to add to IDLE. Very cool: what I imagine is a sort of modular PyLint. > I already did this with tabnanny, > and found that it's barely possible -- it's really written to run like > a script. Mine definitely isn't: it's designed to run both like a script and like a module. One outstanding bug: no docos. To be supplied upon request <0.5 wink>. I just wanted to float it out and see if people think that this particular nanny is worth while. > Since parsing is expensive, we probably want to share the parse tree. Yes. Probably as an AST, and transform to tuples/lists inside the checkers. > Ideas? Here's a strawman API: There's a package called Nanny Every module in that package should have a function called check_ast. It's argument is an AST object, and it's output should be a list of three-tuples: (line-number, error-message, None) or (line-number, error-message, (column-begin, column-end)) (each tuple can be a different form). Problems? (I'm CCing to python-dev. Please follow up to that discussion to python-dev only, as I don't believe it belongs in patches) -- Moshe Zadka <mzadka@geocities.com>. http://www.oreilly.com/news/prescod_0300.html
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4