Preface: The existing approach of using subprocess(http://bugs.python.org/issue21880), did not yield good result on 3 major platforms. In this post, I am outlining an alternate approach -----------
The proposed workflow is as follows IDLE <---> Middleware Generic API <---> Middleware Checker specific API <--> Checker IDLE and middleware generic api will go into Lib/idlelib. Middleware checker specific api will go into site-package(usually a single file). Checker, depends, but currently most checkers go into site-packages anyways. So, what happens is: Whenever IDLE receives a request to check a file with a checker, it requests the middleware generic api, passing on all parameters as necessary. The middleware generic api's only function is to pass on the requests to the middleware checker specific api and return the results back to IDLE. The middleware checker specific api, will *import* the checker and do the processing. It will return the result,(after formatting if necessary). Getting the checker specific api file into the users system could be done through existing framework: pip To ensure that the checker is present on the users system, we could mark it as a dependency when uploading to PyPI. For the middleware generic api to detect existing checkers: Create a idlelib specific folder in site-packages(i.e. every middleware checker specific api file to be placed into site-packages/idlelib/ to enable detection) Installation of middleware checker api could be done via command line.(We could also support from inside IDLE, but that is a separate issue altogether) It could be something like : pip install idle-checker-x etc. My proposal will avoid 'favoritism' in the checkers supported as well as not hardcode any checker(and its interface to IDLE) into idlelib -- Regards Saimadhav Heblikar _______________________________________________ IDLE-dev mailing list IDLE-dev@python.org https://mail.python.org/mailman/listinfo/idle-dev