[Python-Dev] When to signal an error

Jeremy Hylton jeremy@alum.mit.edu
Sun, 20 Jan 2002 17:43:59 -0500


>>>>> "NN" == Neal Norwitz <neal@metaslash.com> writes:

  NN> Guido van Rossum wrote:
  >> I believe that evertually some PyChecker-like technology will be
  >> incorporated in the Python compiler.  The same happened to C
  >> compilers: the lint program became useless once GCC incorporated
  >> the same technology.

  NN> pychecker was (and still is) an experiment to me.  But I think
  NN> it would be great if the lessons from pychecker could be
  NN> integrated into the compiler.

Me, too.

  NN> I'd be happy to help the process of integrating warnings into
  NN> the compiler, however, I'm not sure how to proceed.  Should
  NN> pychecker be put into the standard library (users can now do:
  NN> import pychecker.checker and all modules imported are checked by
  NN> installing an __import__)?  Should pychecker be added as a tool?
  NN> Should a PEP be written?  etc.

How much of pychecker's work could be done by the compiler itself?
I'd like to see more of the warnings generated during compilation, but
agree with Michael Hudson that extending it is a lot of work.  Perhaps
it's time to redesign the compiler.

A PEP is probably good for more than one reason.  One reason is to
document the warnings that are generated and the rationale for them.
If you integrate it into the compiler, the PEP is a good place to
capture some design info.

Jeremy