>>>>> "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
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