Project ideas for Python Core in GSoC 2013
1. Work on Email enhancements. Possible projects:
- 1.1 Add header-type-specific parsing for additional header types (Received, Message-Id, References) to the new 3.3 provisional policies.
1.2 Work on support for RFC 6532 in the email package.
1.3 Work on support for RFC 6531 in smtplib and/or smtpd.
2. IDLE Improvements (mentor: Todd Rovito email: rovitotv at gmail.com). Don't spend your summer IDLE around the swimming pool spend your summer working on IDLE and make a difference. IDLE is Python's Integrated Development Environment (IDE) that is shipped with each Python release, wikipedia has the details here http://en.wikipedia.org/wiki/IDLE_(Python). Many years ago I learned Python with IDLE as do many people, while I personally find IDLE a usable tool IDLE does have it's quarks and bugs which have been documented here:
http://inventwithpython.com/blog/2011/11/29/the-things-i-hate-about-idle-that-i-wish-someone-would-fix/ here is a meta-issue in the Python bug tracker describing IDLE's current state as related to this blog http://bugs.python.org/issue13504
Since IDLE ships with Python it is often the first IDE a new Python programmer uses. We want to make IDLE an awesome experience especially for people that are learning Python. IDLE should remain a simple and clean interface based on tkinter like it always has been. This effort is not a radical departure from what already exists but seeks to build a test framework for IDLE, test patches in the issue tracker, and document IDLE. Recently the Python community has accepted PEP-434 (http://www.python.org/dev/peps/pep-0434/) which is a Python Enhancement Proposal that is designed to allow enhancement exceptions for all Python branches. This would allow students working on this project to actually see their hard work get shipped in the next official version of Python 2.7.5, Python 3.2.5, and Python 3.3.1. Suggested ideas for inclusion in a successful proposal:
Create a unit test framework for IDLE see http://bugs.python.org/issue15392. One of the major problems with IDLE is the lack of unit tests. tkinter has unit tests and could be the basis of a unit test framework for IDLE. The unit test frame work needs to support the build bots and help developers quickly test new patches from the issue tracker. Currently each new patch has to be hand tested which can consume time. The lack of a unit test framework hinders IDLE development and is one of the primary reasons why patches don't get committed to the Python source tree.
Create an IDLE extension that would integrate PEP8 (Syntax Style Checker) https://pypi.python.org/pypi/pep8 into the IDLE editor window. Many modern IDE's have not only syntax highlighting but on the fly syntax checking.
Similar to above but create an IDLE extension that would integrate PyFlakes (passive checker of Python programs) https://pypi.python.org/pypi/pyflakes/0.6.1 into the IDLE editor window. Many modern IDE's have not only syntax highlighting but on the fly error checking.
Potential students should consider how important unit testing is in the real world, where else are you going to be able to learn unit testing skills with a product that has millions of users? While building a unit test framework is not glamours unit testing does find bugs early and improve the overall quality of the Python code base. Every night the unit test frameworks built into CPython are automatically executed on multiple computer architectures and operating systems http://python.org/dev/buildbot. Successful student proposals should not under estimate how long it takes to get code committed to CPython. A student must be able to concisely communicate and document the unit test framework's design to the Python community in order to get the framework committed to the CPython source tree. Do not underestimate how much time this communication and documentation will actually take in your proposal!!! Often times it will take several passes and several code reviews for a patch to get committed into CPython. This project is approximately 40% coding and 60% communication. This project requires average Python coding skills with excellent communication skills and a unrelenting persistence to get this job done to the satisfaction of at least one Python Core Developer so the work will be committed into the CPython source tree. To get started a student should read the Python Developer's Guide (http://docs.python.org/devguide/) and learn about unit testing (http://en.wikipedia.org/wiki/Unit_testing and http://docs.python.org/3.4/library/unittest.html). Please write your proposal carefully. Proposals should not be long but should quickly demonstrate to the reader that the proposer has the skills to make this project a success. A great book on Technical Writing is Leo Finkelstein's "Pocket Book of Technical Writing for Engineers & Scientists" (http://www.amazon.com/Technical-Writing-Engineers-Scientists-McGraw-Hills/dp/0073191590/ref=la_B001IQXQLU_1_1?ie=UTF8&qid=1365870140&sr=1-1), which has a great section on how to write a proposal. As mentioned in the Wiki for Python Google Summer of Code 2013 (http://wiki.python.org/moin/SummerOfCode/2013) contribute at least one patch for IDLE or perhaps a patch that develops a unit test for another Python module. Of course the more patches submitted before proposals are due the better!!! Prospective students should also complete the Python Contributor Agreement (http://www.python.org/psf/contrib/). Then be sure to include a link to the submitted patch(s) in the proposal. Patches do not have to be accepted by proposal time. By submitting patches a perspective student will demonstrate they understand the Python tool chain and have read the Python Developer's Guide. Feel free to contact the mentor of this project Todd Rovito (rovitotv at gmail dot com) to discuss your proposal. Another great source to ask questions and get feedback on your proposal is the idle-dev mailing list (http://mail.python.org/mailman/listinfo/idle-dev). Here is a application template that the Python Software Foundation expects each proposal to follow, http://wiki.python.org/moin/SummerOfCode/ApplicationTemplate2013 .