Differences between revisions 8 and 9
Revision 8 as of 2013-04-12 03:15:42
Size: 3297
Editor: rovitotv
Comment:
Revision 9 as of 2013-04-12 03:56:27
Size: 5269
Editor: rovitotv
Comment:
Deletions are marked like this. Additions are marked like this.
Line 13: Line 13:
3. IDLE Improvements (mentor Todd Rovito rovitotv at gmail.com). 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 it does have it's quarks and bugs which have been documented here: 3. 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:
Line 17: Line 17:
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 new to 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: 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:
Line 24: Line 24:
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 fair 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). 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).

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. Finish the work on PEP 3154, started as part of GSoC 2012. See http://bugs.python.org/issue15642

3. 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:

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 fair 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). 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).

SummerOfCode/2013/python-core (last edited 2013-04-23 01:57:21 by rovitotv)

Unable to edit the page? See the FrontPage for instructions.