New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IDLE: Integrate external code analysis tools #62904
Comments
This is to create an IDLE extension that would integrate PEP-8 (Syntax Style Checker https://pypi.python.org/pypi/pep8 ) into the IDLE editor window,so the developer who is using the IDLE editor can quickly and frequently check the PEP-8 standards of the code which is being developed in an IDLE editor window. Many modern IDE's have not only syntax highlighting but on the fly syntax checking. Python ensures the quality of code with its own standards implemented as PEP-8. The tool PEP-8 checks Python code against some of the style conventions in PEP-8. Also the PEP-8 standardization should not be a ‘must emphasizing’ for a python developer, therefore configuring PEP-8 to enable/disable errors and warning in various levels should be implemented. The implementation work is started by Todd at https://bitbucket.org/rovitotv/pythonpatches/src/fae1fdab936043ec35db541808f5789325762fb3/PEP8CheckExtension.patch?at=default The submitted patch is an effort started from Todd's patch as an example. This is an initial work and I am looking forward for suggestions on improvements and mistakes of this patch. |
I like the idea of having a PEP-8-checker for IDLE. |
-1 on giving PEP-8 any more weight than it already has. Automated PEP-8 checker tools do away the human commen sense component (the foolish consistency quote is in PEP-8 for a reason). Another downside is that rigid adherence to PEP-8 tends to focus beginners on the least important aspects of code quality. We would be much better-off with integration of PyFlakes or a similar tool that focus on actual semantic errors in the code. |
Can't this be developed as an external extension? |
Ezio, [1] Wikipeida Microsoft Visual Studio, http://en.wikipedia.org/wiki/Microsoft_Visual_Studio#Code_editor |
Raymond, |
Mine doesn't :)
That's a standard though, the ones in PEP-8 are just conventions/guidelines/suggestions.
AFAIU PyFlakes should be able to catch actual problems with the code -- not just simply suggesting a particular style -- so it would be a better candidate.
Often editors are able to download extensions automatically from a central place, without having to ship them all by default. Doing this is probably more work though, but on the other hand it would be more flexible.
Are you suggesting to include it directly in the stdlib, and not as part of IDLE?
Note that that's not the only issue. Even if the license is OK, before inclusion we would have to make sure that the module meets the quality standards for the repo and that the author is still active and willing to maintain it for at least a few years in the CPython repo. A PEP would likely be required, especially if the module gets included directly in the stdlib (as opposed as including it just in IDLE). This also means that external development of the module should stop and move to the stdlib, and follow the release schedule of Python instead of release whenever they want (in theory they could maintain both, but it's more work). |
Summary: Alternatives: when and how to analyze.
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.
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. |
Agree with Terry Reedy. |
Thanks for showing great interest on this idea. Anyway to keep in touch with the Python analyzing and related tools, I have initiated a separate project with porting the works done on the patch here https://github.com/Jay-Krish/IDLEAnalyzer. |
[TJR]
[Ramchandra Apte]
[R. Jayakrishnan]
I agree as well. |
I would prefer this issue concludes with a navigation to the new proposed enhancement. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: