Summary:
I am in favor of making more Python code analysis available from within Idle. I have an alternate, more generalized proposal. I am opposed to this specific proposal and think this issue should be closed.

Alternatives: when and how to analyze.

1. Local analysis as the user types ('on the fly'). One example is smart indentation, which includes conversion of \t to spaces (this is PEP 8 enforcement!) and backspace to multiple deletes. Others are calltips and code completion.  We might consider doing a bit more syntax checking, but would have to be very careful about style enforcement.

2. Block or whole file analysis within the text widget upon user request. Examples include search, reformatting, and whitespace stripping. The result is shown within the text widget (except for the bug on Windows that search still does not highlight found results while the dialog is active).

3. Analysis of one or more external files with Idle code. 'Find in Files' applies one pattern to file names and another to lines within found files and presents hits in an output (editor) window. The output lines contain file name, line number, and code line formatted so that right click, 'Go to file/line' opens the file if necessary and jumps to the indicated line.

4. Analysis of the saved editor file with external code. 'Run' (normally) does this (and more), with the complication that a socket rather than stdio streams are used for communication. Results appear in the shell window. Although tracebacks put file name and line number on one line and code on the next, 'Go to file/line' works when either is right-clicked. (Although Run now uses the same interpreter that is running Idle, this does not necessarily have to be so.)


Proposal: Run with ... 

What I would like to see is a generic option to save and run the current window with appropriate external programs. This proposal combines ideas from 3. and 4. above. The interface would be the addition of 'Run with ...' to the Run menu. Selecting that would bring up a submenu.

I would use subprocess to start the program (as is done with Run now). A command-line template would be needed for each supported external program. Unlike Run, subprocess would be used to capture stdout and stderr, as needed. The filtered output would be presented in a new Output Window, as done with Find-in-Files.

To me, the main value-added of doing this from Idle is being able to jump from output chunks to targets in an editor window for possible editing. I would only officially support external programs for which this is sensible, whose output includes line numbers and messages for possible action. Each supported program would need an output filter function to add the filename (if not present) to the line number and message and otherwise format as needed.

This proposal needs more details. how are external programs located if installed? (Ezio suggested the possibility of easy download and installation if not. I would start with instructions in the docs.) How is the submenu populated. How might users add templates and filter functions for programs not supported?  Such program might include locally written programs. There should be a PEP or at least PEP-like specification. Since the only stdlib addition would be to idlelib, backporting could be considered.


What I think is wrong with the current proposal.

1. There is no specification.

2. It is limited to one category of analysis. Within that category, it 'plays favorites' by picking a winner. I think users should be able to use whatever style analysis program they have already chosen, with the configuration options they have already selected. Not yet mentioned here are PyLint and PyChecker.

3. Rather than pick the 'best of breed' (if there is one), it picks what some would consider to be the 'worst of breed'. The PEP8 module, or at least the way it has been used, violates PEP 8 by treating guidelines as rigid rules, even though PEP 8 says not to do that. Some of the recent edits to PEP 8 were intended to counteract the negative effect of this module.

4. It proposes to add an external program to the stdlib without the needed PEP. I believe the idea of adding one of PyChecker, PyFlakes, and PyLint has already been rejected for multiple reasons (there is no winner, these are apps or tools, not library 'batteries', they are better off maintained where they are, we cannot maintain what we already have, etc.). The fact that these programs have (or should have) persistent configuration and customization files shows that they are apps, like Idle, and not library modules.

5. It proposes to add the external program in the wrong place. Idlelib should only contain Idle-specific code. Need I add that Idle is also under-maintained?

My proposal would start with a specification, would allow user choice, would generalize to other categories and programs (spell checking?), would not expand the stdlib, and would only add idle-specific glue code to idlelib.