Differences between revisions 1 and 7 (spanning 6 versions)
Revision 1 as of 2014-02-14 02:31:22
Size: 2577
Comment:
Revision 7 as of 2014-02-26 10:56:43
Size: 3553
Editor: berkerpeksag
Comment: Fix markup in email section.
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= Project ideas for Python Core in GSoC 2013 = = Project ideas for Python Core in GSoC 2014 =
Students interested in "Python Core" projects will be working on the [[http://en.wikipedia.org/wiki/CPython|CPython]] Python language interpreter and related core packages.
Line 3: Line 4:
== Email == == Getting in touch with mentors ==
There are two important lists for students interested in Core Python development:
Line 5: Line 7:
=== Possible email projects ===  * https://mail.python.org/mailman/listinfo/python-dev is the main development list for python.
 * https://mail.python.org/mailman/listinfo/core-mentorship is the introductory list for people just getting started in Python development, and as such is usually the place for new students to start communicating with mentors and getting their environment set up.
Line 7: Line 10:
    1.1 Add header-type-specific parsing for additional header types (Received, Message-Id, References) to the new 3.3 provisional policies. Students should subscribe to and read both lists, but should use the core-mentorship list to post questions and get started.
Line 9: Line 12:
    1.2 Work on support for [[http://tools.ietf.org/html/rfc6532|RFC 6532]] in the email package. == Getting Started ==
In addition to the mailing lists, students interested in contributing to core Python should take a look at the [[http://docs.python.org/devguide/|Developers guide]]
Line 11: Line 15:
    1.3 Work on support for [[http://tools.ietf.org/html/rfc6531|RFC 6531]] in smtplib and/or smtpd. ----
Line 13: Line 17:
== IDLE == == Projects ==
=== Email ===
==== Possible email 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 [[http://tools.ietf.org/html/rfc6532|RFC 6532]] in the email package.
 . 1.3 Work on support for [[http://tools.ietf.org/html/rfc6531|RFC 6531]] in smtplib and/or smtpd.
Line 15: Line 24:
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. === IDLE ===
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. 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.
Line 17: Line 27:
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. ==== Possible IDLE projects ====
 * A unit test framework for Idle was created in the spring and summer of 2013. Some test modules created by 2013 GSOC students were created within the framework and are now part of Python's daily tests on multiple systems and versions. There is still much more to add. One priority project would be to add tests for existing tracker bug and enhancement issues. Another would be a non-buildbot human test to sequentially display every window and dialog to check that they do display without raising an exception and that they look 'correct'.
Line 19: Line 30:
=== Possible IDLE projects ===  * Create an Idle extension that would integrate 3rd party code checkers with Editor Windows. See message 195711 of http://bugs.python.org/issue18704.
Line 21: Line 32:
  * 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.  * Add an option to connect to user subprocesses with subprocess.Popen and pipes. If this works well enough, it could replace the current connection by sockets, which sometimes fails. http://bugs.python.org/issue18823
Line 23: Line 34:
  * 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.  * Make Idle more completely a GUI application by using popup windows rather than a console to report errors. The latter is a problem when there is no visible console, as is normal on Windows.
Line 25: Line 36:
  * 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.  * Optionally add line numbers to code in an edit window. The underlying tk Text widget apparently keeps track of line numbers, but Idle can only control its behavior through the interface made available. So what is possible might be less than what we would like.

 * In the shell window, separate prompts from input or output. Or otherwise make it possible to use 4 space indents, at least after the first.

 * Look at other Idle enhancement issues on the tracker. However, inquire first since not all ideas on the tracker will ever be accepted.

Project ideas for Python Core in GSoC 2014

Students interested in "Python Core" projects will be working on the CPython Python language interpreter and related core packages.

Getting in touch with mentors

There are two important lists for students interested in Core Python development:

Students should subscribe to and read both lists, but should use the core-mentorship list to post questions and get started.

Getting Started

In addition to the mailing lists, students interested in contributing to core Python should take a look at the Developers guide


Projects

Email

Possible email 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.

IDLE

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

Possible IDLE projects

  • A unit test framework for Idle was created in the spring and summer of 2013. Some test modules created by 2013 GSOC students were created within the framework and are now part of Python's daily tests on multiple systems and versions. There is still much more to add. One priority project would be to add tests for existing tracker bug and enhancement issues. Another would be a non-buildbot human test to sequentially display every window and dialog to check that they do display without raising an exception and that they look 'correct'.
  • Create an Idle extension that would integrate 3rd party code checkers with Editor Windows. See message 195711 of http://bugs.python.org/issue18704.

  • Add an option to connect to user subprocesses with subprocess.Popen and pipes. If this works well enough, it could replace the current connection by sockets, which sometimes fails. http://bugs.python.org/issue18823

  • Make Idle more completely a GUI application by using popup windows rather than a console to report errors. The latter is a problem when there is no visible console, as is normal on Windows.
  • Optionally add line numbers to code in an edit window. The underlying tk Text widget apparently keeps track of line numbers, but Idle can only control its behavior through the interface made available. So what is possible might be less than what we would like.
  • In the shell window, separate prompts from input or output. Or otherwise make it possible to use 4 space indents, at least after the first.
  • Look at other Idle enhancement issues on the tracker. However, inquire first since not all ideas on the tracker will ever be accepted.

SummerOfCode/2014/python-core (last edited 2014-03-11 18:30:41 by JessicaMcKellar)

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