1. Suborganisation Information :  Core Python

2. Student Information :

Name:Saimadhav A Heblikar

Timezone : Indian Standard Time (IST) UTC +5:30

IRC handle including network :sahutd@irc.network.tld

Source control username : sahutd(Do not have commit rights. Will coordinate with a core          developer/mentor)

Bug tracker username : sahutd (http://bugs.python.org/user18939)

Homepage :http://www.saimadhav.com

Blog :http://blog.saimadhav.com/search/label/gsoc

GSOC Blog RSS Feed : http://blog.saimadhav.com/feeds/posts/default/-/gsoc

Github : sahutd

3. University Information :

University : PES University(formerly PES Institute of Technology)

Major :  Computer Science and Engineering

Current Year and Expected Graduation date : First Year(Freshman), May 2017

Degree : Bachelor of Engineering (B.E.)

4. Project Proposal Information:

4.1 Title - Core Python - Improvements to IDLE


IDLE is a IDE which comes bundled with Python. It currently lacks full test coverage, and misses some common features like line-numbering and ability to integrate 3rd party code checkers. These are few issues with IDLE which make it a “disposable” IDE – novices use it only to later leave to another IDE, once they have gained some knowledge. The project aims to address these issues by extending IDLE test coverage, adding of line numbering and ability to integrate 3rd party code checkers.

4.3 Detailed Description

4.3.0 Background, motivation and general information.

The proposed project consists of four sub-projects.

A) Creating a framework for non-buildbot GUI tests for IDLE

As on date, only 25 of the nearly 60 modules in idlelib have a if '__name__'==.... statement, which brings up a tkinter GUI widget for that module. Behavior depends on the way they were started. Also, some open directly and some bring up a GUI window with a button to  open them. Some do not terminate at all. It is currently non-intuitive to an end user. It is not uniform. This subproject aims to  standardize the process of non-buildbot human testing and to add non-buildbot tests to IDLE.

More information about this issue is found here .[1]

B) Extending the unittest framework for IDLE :

Only 13 of the nearly 60 modules in idlelib are covered by tests. This sub-project aims to extend test coverage for IDLE. Priority will be given to those modules with open issues on the bug tracker and modules which will be required as a part of sub-project C and sub-project D. (read below)

C) Adding line numbering feature to IDLE with breakpoints integration for debugging.

Line numbering is a feature found in most modern IDE's, but is missing in IDLE.

Currently, the user has no way of knowing what is on a particular line or the linenumber of a particular piece of text, without navigating away from the current line. This sub-project proposes to add a sidebar containing line number information. It also proposes to integrate breakpoints during debugging. This would also make the Goto dialog in Edit menu more useful.

D) Creating a framework to integrate 3rd party code checkers into EditorWindow

The problem with 3rd party code checkers is that there is no “perfect” checker. We could either support all or nothing. Biggest hindrance is that they are not library classes and do not belong to the stdlib. This aspect is preventing the addition of any 3rd party code checker. This sub-project aims to create a framework where 3rd party code checkers can be easily added (and removed) from IDLE without disturbing the stdlib.

4.3.1 Project Goals and deliverables

A) Creating a framework for non-buildbot GUI tests for IDLE

Initiate the process. Discuss with other developers on the standards to be followed and the naming convention. Based on the discussions and agreed upon standards, add GUI tests to the modules. Document the process of adding non-buildbot human tests.

B) Extending the unittest framework for IDLE :

To extend the number of tests in IDLE by a substantial amount with priority as described above. Extension of mock methods to aid the same

C) Adding line numbering feature to IDLE with breakpoints integration for debugging.

Add the line numbering feature to IDLE with the possibility to select breakpoints for debugging. NS:This feature will only apply to non-shell Editor Window instances. For what to expect from this sub-project, please view the mock-up[2] and image[15]

D) Creating a framework to integrate 3rd party code checkers into EditorWindow

Initiate discussion about the standards to be followed - what type of checkers to allow(i.e. whether they would be static analyzers or not, whether they would have permission to execute the code etc.). Create the framework based on the discussions. Add at-least one 3rd party code checker as an example on how to integrate other 3rd party code checkers. Document the process, in order to allow other developers to use the framework.

4.3.2 Technical and implementation details

A) Creating a framework for non-buildbot GUI tests for IDLE

Proposal involves displaying a root window having information about the module to be GUI tested. This window will have information about the expected behavior of the module and a button to start that module. Once its started, the user will “test” it. The user will then be given choices to “pass the test” or raise an exception, in case of an error. The result of the users choice will be sent back to the console. A new file htest.py with methods named human_test_module_name, may be used, to avoid confusion with the current test_* - both to the unittest suite and the tester. The proposed non-buildbot tests and current regular unittests will be separate, though they will be called from the same “if __name__==....” part.

B) Extending the unittest framework for IDLE

Will follow the current style of writing tests. It will be written as per instructions in the readme file [3]. For examples of what to expect, here are tests which I have written for IDLE. Link 1 ;Link 2[4][5]

C) Adding line numbering feature to IDLE with breakpoints integration for debugging. 

For a better understanding of the implementation detailed below, please view the mock-up[2]. The description is based on the same code as the mock-up. This feature is applicable only to non-shell Editor window instances.

This sub-project has two parts

i. Adding the line numbering feature

Tkinter’s canvas will provide the base canvas. The canvas itself will be a thin vertical strip to the left of the text area in Editorwindow. “Create_text()” will be used display the lines. To extract what lines are in current view, the text widget's dlineinfo method will be used iteratively. There are many ways in which the current view can be changed, these include insert, delete, replace, scrolling, window resizing etc. There are no built in callback functions to handle all of these events. To overcome this issue, low level calls will be intercepted. Tk.eval will be used  to check if they have events which may alter the current view. If they do, the canvas will be re-rendered.

ii. Integrating breakpoints with line numbering feature -

Breakpoints will toggled on and off when the user clicks on them. The mouse event <Button-1> on the canvas will trigger an event to retrieve the id of the object on which the mouse was clicked. The id of the object clicked is used to extract the  text of that object(which is the line number). This extraction is done using canvas.itemcget(). The line number is  added to the list of breakpoints using “self.set_breakpoint_here()”. Similar procedure is used to turn off the breakpoints for a particular line using “self.clear_breakpoint_here()” (Both methods already present in IDLE). To make it more intuitive to the user, line’s  which have breakpoints set, will be highlighted using create_oval()

D) Creating a framework to integrate 3rd party code checkers into EditorWindow

A new  API for communication between the EditorWindow instance and the 3rd party checker is proposed. The API will provide a standard abstract class based on which the 3rd party code checkers have to provide a class file for integration with IDLE. Only the abstract class file along with its delegator and helper methods will be added to the stdlib. The 3rd party integration classes can be located anywhere and will not be a part of stdlib.

Working:To describe its working, assume pyflakes is the 3rd party code checker to be integrated.

For a sketch of the workflow, please see the diagram [6]

The delegator method returns an object of the pyflakes checker api, which inherits from the above mentioned abstract checker class. The service_caller() is responsible for running pyflakes. It would use Subprocess.Popen to do so. The result of this call, which is the data returned by the 3rd party code checker is stored in “raw_result”. The formatter() formats the “raw_result” to the standard form. The standard form should at-least have information about filename, line-number and error message for usefulness. Based on the requirements, the formatted result may either be displayed in a new window or be sent back to the EditorWindow instance. The visual aspect will be similar to the current Find-in-files grep dialog.

4.3.3 Mockups

A mockup for sub-project C) Adding line numbering feature to IDLE with breakpoints integration for debugging is available at[2][15]. Mockup and image

4.3.4 Some use cases and benefits to the community

A) Creating a framework for non-buildbot GUI tests for IDLE

Though a module may pass unittests, it may appear differently than intended. One of the uses of non-buildbot human tests are during release time, when you have to ensure everything is perfect.

B) Extending the unittest framework for IDLE

This sub-project will help IDLE developers concentrate on adding features to IDLE than about worrying if they have unintentionally broken something. More modules under test coverage implies  more development time!

C) Adding line numbering feature to IDLE with breakpoints integration for debugging.

Alice and Bob are co-workers. Alice spots a typo in Bob's code. Alice has to count all the way down to that line, and inform Bob about it. Now Bob has to repeat the process too! This sub-project will save Alice and Bob a lot of trouble.

D) Creating a framework to integrate 3rd party code checkers into EditorWindow

Allows to integrate ANY 3rd party checker. IDLE developers need not maintain any code but IDLE users can virtually use tools ranging from linters, pep8 formatters to even spell checkers.

4.4 Timeline ( Weekly timeline)

Week 0 – 21 April to 18 May – Community Bonding Period

Get to know mentors. Discuss communication methods. Make to-dos, design documents, and  plans on how to move forward. Make  a detailed description on how to implement subprojects A, C and D . These will be required for feedback which I will require before I begin work on the respective subprojects.

Week 1 – 19 May to 25 May

Begin work on sub-project A based on feedback obtained.

Finalize the standards for creating non-buildbot human GUI tests

Expectation : To have put down a standard for non-buildbot tests. Extended the framework for the same.

Week 2 – 26 May to 1 June

Continue work on Sub-project A. Create documentation on how to add non-buildbot tests.

Expectation : To have substantially increased the number of modules under non-buildbot test coverage.

Week 3 – 2 June to 8 June

Work on sub-project A. - Extend tests for IDLE

Expectation : To have increased the test coverage. Prioritize modules with open issues on bug tracker.

Week 4 – 9 June to 15 June

Extending unittest framework as a part of sub-project A.

Initiate discussion on Sub-project C in idledev/core-mentorship based on detailed proposal for adding line numbering to IDLE with integration for breakpoints during debugging.

Expectation : To have increased test coverage by a substantial amount.

Week 5 – 16 June to 22 June

Begin and complete work on adding line-numbering to IDLE as a part of subproject C. Add tests(if any) to reflect the new additions

Initiate discussion about adding 3rd party code checker. Ask for feedback about my proposed way of doing it.

Expectation : To have a working line-numbering feature in IDLE


Week 6 – 23 June to 29 June

Integration of breakpoints to line-numbering work done in the previous week. Modify tests(if any) to reflect the additions. Create documentation about sub-project C for future IDLE development.

Expectation : To have integrated breakpoints to line-numbering added in the previous week.

23 June to 27 June – Submit midterm evaluations.

Week 7 – 30 June to 6 July

Begin work on defining an API for interaction between EditorWindow and 3rd party code checker.

Create an abstract code checker interface for 3rd party checker's to be modeled on. Refine at each stage based on feedback.

Expectation : To have a clear idea about the specifications of the proposed interface and to have begun work on the same.

Week 8 – 7 July to 13 July

Complete leftover work from previous week wrt to the interface.

Add a 3rd party code checker as an example on how to use the new interface to integrate into idle.

Expectation :  A working 3rd party code checker API with at least one example

Week 9 – 14 July to 20 July

Make changes to IDLE dialog's, keybindings, user help files, to reflect changes made in Week 7 and Week 8. Create a dialog window to allow the user to configure 3rd party code checkers

Expectation:To reach a state where the end user should be able to add/remove 3rd party code checkers from within IDLE

Week 10 – 21 July to 27 July

Create developer documentation on how to integrate 3rd party code checker tools with IDLE.

Add tests for features created in Weeks 8, 9 and 10.

Week 11 – 28 July to 3 August

Backup week 1 – For any unforeseen issues. Will be inserted anywhere in the timeline if required. Otherwise to be used for completing tasks or fixing issues on bug tracker

Week 12 – 4 August to 10 August

Backup week 2 – For any unforeseen issues. Will be inserted anywhere in the timeline if required. Otherwise to be used for completing tasks or fixing issues on bug tracker

11 August– Pencil Down date

11 August to 17 August

Correct any glitches, bugs, update documentation, finish incomplete tests and make sure the code is ready to be reviewed and committed.

18 August – Submit final evaluations and code-samples to Google.

4.5 Link to patches

Adds idle test for configHelpSourceEdit [4]

IDLE: Extend tests for PathBrowser [5]

IDLE : Display function argument list in ClassBrowser [7]

Idle options dialog: add help [8]

IDLE test : Typo in readme file [9] (committed)

Adds missing backslash to devguide setup page[16](committed)

Minor typo in enum docs [11] (committed)

os.exec* mangles argv on windows (splits on spaces, etc) [10]




5.General Information

This section is used to convey how I plan to execute the above tasks throughout GSoC 2014.

  1. I will be in constant touch with my mentor on a periodic basis.
  2. I will be in constant touch with the community through regular channels like mailing list and IRC.
  3. Will follow the practice of iterative development. I will make the community and my mentor aware about how I plan to go about implementing a particular feature about a week before I begin working on it, so that we are all on the same page and I don’t waste everyone's time. This would also be helpful in obtaining feedback and make changes appropriately.
  4. I plan to stick to the stated timeline and keep up with the program's requirement of working atleast 40 hours a week throughout GSoC 2014.

6. References

[1]Idle: make human-mediated GUI tests usable


[2]Mock-up of line numbering integrated with breakpoints


[3]Idlelib tests readme file


[4] Adds idle test for configHelpSourceEdit


[5] IDLE: Extend tests for PathBrowser


[6]3rd party code checker workflow diagram


[7]IDLE : Display function argument list in ClassBrowser


[8]Idle options dialog: add help


[9]IDLE test : Typo in readme file


[10]os.exec* mangles argv on windows (splits on spaces, etc)


[11]Minor typo in enum docs


[15] Image of line-numbering mockup


[16]Adds missing backslash to devguide setup page