GSoC 2014 Summary blog post

Three months of coding, Python, code reviews, IRC meet's, emails sent back and forth, filing bug reports, getting bug reports, submitting patches and I could just go on and on! The past three months have been the most exciting and productive three months, in terms of programming, EVER! GSoC 2014 has been an eye opening experience for me. I can finally claim to understand *some* of the internal working of Python.

Experiences

Taking a look back, before GSoC14 began, I had confined myself to writing small utility scripts. It was something that would be used by me and me alone. I could change the API's as I wished. API Design? What the hell is that!? How things have changed in a matter of three months. I have learnt so much, too much to list in a single blog post, that I will just skim over my GSoC 2014 experiences. You can read my other blog posts tagged <gsoc> to take a look at what I actually did in the 3 months.

There is more than one way to do it, but there is only one CORRECT way

Many times in the past, I'd often be happy with the first solution that works. I would move on after I had a solution. During GSoC, I have learnt through experience that the while the first solution that clicks, could work, there is usually another(and better) way of solving the same problem. I had this experience in 3 of the 4 of my subprojects - namely : non-buildbot test framework, linenumbering(and a second linenumbering approach) and Checkers. I am really proud to say that I have submitted atleast 2 different approaches for each of them, and we have had the luxury to pick and choose solutions.

Writing code for a (standard) library package

As you are hopefully aware, IDLE is a Python standard library package. This has many implications, an important one being, changing existing code is a very difficult decision to make - you don't know how it is going to break someone else's setup. You also know it WILL break something. You have to work with what you have. This requires a lot of skill and an even greater understanding the codebase that you are working on. I feel I have picked up some of it - I feel I can now jump into any codebase and fix a bug or add a feature without creating some new 10 bugs in the process. GSoC has given me that confidence.

That test driven development is great

It was through GSoC that I learnt about Test Driven Development(TDD) and testing. I have used this methodology while working on the Linenumbering and 3rd party code checker subprojects. I feel it is a great philosophy. It forces you to think of the behavior, define that behavior, the desired API etc, all this before you write a single line of code. It has and will prevent me from jumping straight into coding - a recipe for disaster.

Successes

I feel I have met the expectation that I set before I started out.  Two subprojects - non-buildbot test framework and unittest framework have been completed and committed to the python source tree. The third subproject - linenumbering is on the verge of being committed.

Roadblocks

The fourth subproject, though fully functional, I have to admit is quite far from being a part of the IDLE source. I feel it is still some rounds of code review and improvements away from being "complete". This subproject is lagging behind other's in terms of completeness. 

Looking forward...

Irrespective of what I did do and was not able to do, GSoC has been a great learning experience for me. Needless to say, I will continue with my contributions to the CPython project. I will also hopefully be able to contribute to other parts of it as well.

With a heavy heart, and loads of memories,
Saimadhav Heblikar