Terry J. Reedy added the comment:
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.
----------
stage: -> patch review
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue18704>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
