Mark> On my third hand, I would _really_ like to see this in a lint tool
Mark> rather than in the core. I realize there is no such tool at the
Mark> moment, but IMO is where we should be heading. Skip's return
Mark> statement warnings are fine and a nice addition, but in my
Mark> experience account for a trivial number of my errors. Stuff like
Mark> warning about a variable name used only once, for example, will
Mark> probably never get into core Python but in my opinion is far more
Mark> valuable. So adding this "-w" switch is fine, but still doesnt
Mark> give us the framework we need to actually create a truly useful
Mark> package of warnings for the Python developer.
I'm not sure the stuff I wrote belongs in the core either, certainly not in
C code. As I mentioned when I posted it though, I wasn't sure where a
PyLint type program already existed that I could simply graft onto. I've
fiddled around enough with the compile.c code in the past couple of years
that I understand it fairly well already.
I do have some Python code that does peephole optimization on Python
bytecode. I could have put it in there (it already divides functions into
basic blocks), but again, not many people have it laying about to play with.
Can we start/settle on a Python-based source code framework for this sort of
thing? Ideally, I'd like to see a framework that brings the parser module's
output up to a level where mere mortals like me can reason about Python
code.
Skip
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