[Python-Dev] Where does lint-like functionality belong?

[Skip Montanaro]

Okay, if Tim's assertions are correct (and I have no reason to suspect
them), a separate pylint will be doomed, so the only reasonable thing to do
is to place it in the core where it will be rarin' to go all the time.
Perl's experience with -w seems to suggest that it's best to always enable
whatever warnings you can as well.  (More and more I see people using gcc's
-Wall flag as well.)

Now, my return consistency stuff was easy enough to write in C for two
reasons.  One, I'm fairly comfortable with the compile.c code.  Two, adding
my checks required no extra memory management overhead.  Consider a few
other checks you might conceivably add to the byte code compiler:

    * tab nanny stuff (already enabled with -t, right?)
    * variables set but not used
    * variables used before set

If all of this sort of stuff is added to the compiler proper, I predict a
couple major problems will surface:

    * The complexity of the code will increase significantly, making it
      harder to maintain and enhance
    * Fewer and fewer people will be able to approach the code, making it
      less likely that new checks are added
    * Future extensions like pluggable virtual machines will be harder to
      add because their byte code compilers will be harder to integrate into 
      the core

In addition, more global checks probably won't be possible (reasoning about
code across module boundaries for instance) because the compiler's view of
the world is fairly narrow.

I think lint-like tools should be implemented in Python (possibly with the
support of an extension module for performance-critical sections) which is
then called from the compiler proper under appropriate circumstances
(warnings enabled, all necessary modules importable, etc).  I believe the
code would be much more easily maintained and extended.  You'd be able to
swap in a new byte code compiler without risking the loss of your checking
code.

Skip