Differences between revisions 1 and 239 (spanning 238 versions)
Revision 1 as of 2005-06-27 06:59:05
Size: 9185
Comment:
Revision 239 as of 2007-03-05 18:36:43
Size: 4100
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= Python Implementation of the Data Access Protocol = #acl All:read
Line 3: Line 3:
(Roberto Antonio Ferreira De Almeida) This page coordinates the [http://code.google.com/soc/ Google "Summer of Code"] projects involving Python and mentored by the Python Software Foundation (PSF).
Line 5: Line 5:
The Data Access Protocol (DAP) is a data transmission protocol
designed specifically for science data. The protocol relies on the
widely used HTTP and MIME standards, and provides data types to
accommodate gridded data, relational data, and time series, as well as
allowing users to define their own data types. The initiative is
funded by NASA, and counts with the support of several
institutions. Hundreds of scientific datasets are available on the
internet through DAP servers, which can be accessed remotely by DAP
clients in a transparent and efficient way. Here I propose to develop
a Python implementation of the protocol based on its latest
specification. The proposed implementation will consist of a client
module that will allow Python applications to access remote datasets,
as well as a server for data stored in a variety of formats commonly
used by the scientific community, including NetCDF and Matlab files.
Discussion about any Python-related SoC topic should take place on
[http://mail.python.org/mailman/listinfo/soc2006 the soc2006 mailing list].
Line 20: Line 8:
Mentor: Paul DuBois. = Students: How to submit a proposal =

[http://code.google.com/soc/student_signup.html Apply through Google's online form.]

[http://code.google.com/soc/student_step1.html Submit an application.]

The Drupal folks have some good information for students on [http://drupal.org/node/59037 how to write a SoC application]

Here is Google's [http://code.google.com/soc/studentfaq.html Student FAQ].

== Tips on writing your proposal ==

'''Be detailed.'''
Don't say "I want to improve Python's support of XYZ", because that's vague, making it difficult to assess the project's feasibility or the time required. Exactly what changes would you make to improve XYZ support?

'''Compare with alternative projects.'''
If your project will do task XYZ, look at other existing projects
that perform the same task and
explain how yours is different or better. (Or you can write a proposal to finish an existing project instead.)

'''Try to provide a rough timeline.'''
How much time would each change take (a day, a week, six weeks)? What intermediate milestones will there be? (e.g. for a game, you might get an initial graphic display in week 1, write a parser for level definitions in week 2, write a level editor in weeks 3 and 4, etc.)

'''Get feedback.''' Post the proposal to a relevant mailing list and ask for comments. Post the proposal to your weblog and see what people think.

'''Describe your experience.'''
Why are you a good person to work on this project? What skills/interests/knowledge do you have that are applicable?

'''Suggest a mentor.'''
If you know a developer who would be a good mentor for your project,
contact him/her and ask if they're interested. In 2005 and 2006, some interesting projects went unfunded because there was no one in the pool of mentors who felt capable of handling them.

Looking at the list of PSF mentors
can help you craft your proposal to match their interests.
 * ["SummerOfCode/Mentors"]
Line 23: Line 45:
= Interactive Comments & Annotation for the Python Standard Reference = = Tips on participating =
Line 25: Line 47:
(Brian Beck)    1. Do not overbook yourself. Working on your project should be your main activity for the entire summer.
Line 27: Line 49:
A flexible system for comments and annotation on web pages, geared towards
the Python standard reference, using Ajax on the client-side and Python on
the server-side.
   1. Participate in the developer community by joining python-dev, jython-dev, or whatever mailing list is appropriate.
Line 31: Line 51:
Mentors: Ian Bicking, Andrew Kuchling    1. If you get stuck, ask for help instead of silently struggling. You can ask your mentor for help, or post a question to the development mailing list.
Line 33: Line 53:
= Bitten: A Python framework for collecting software metrics from automated builds =    2. You must provide weekly status reports.
Line 35: Line 55:
(Christopher Lenz)
  mentors: gregwilson; trentm | = Bitten: A Python framework for collecting software metrics from automated builds = Today's auto
   3. You will be expected to learn how to use SVN.
 
Line 38: Line 58:
The goal of this work is to design and implementat of a distributed system for automated builds and continuous integration that allows the central collection and storage of software metrics generated during the build. The information collected this way needs to be structured and available in a machine-readable format, so that it can be analyzed, aggregated/correlated and presented after the build itself has completed. = Mentors: How to apply =
Line 40: Line 60:
Mentors: Greg Wilson, Trent Mick. The mentor's responsibility is to ensure the student makes progress. This could entail coaching them, providing motivation, making sure they aren't stuck, answering technical questions, or pointing the student to the proper resources. Mentors should expect to get a weekly status report from their students, and should bug students who are not communicating.
Line 42: Line 62:
= A Program Visualization Tool = However, the mentor is not expected to do work for the student.
Line 44: Line 64:
(Tero Kuusela) Mentoring duties are expected to take a couple of hours per week.
Line 46: Line 66:
The goal is to write, in Python, a functional program visualization
tool that can visualize Python code. With the visualization tool, one
can write a program and see the execution visualized to help
understanding how the program works. This is especially useful to
assist students learning how to program.
[http://code.google.com/soc/mentor_step1.html Apply through Google's online form.]
Line 52: Line 68:
Mentor: David Ascher.  * [http://mail.python.org/pipermail/python-dev/2006-April/063965.html Announcement made to Python-Dev]
 * [http://code.google.com/soc/mentorfaq.html Mentor FAQ]
Line 55: Line 72:
== Project ideas ==
Line 56: Line 74:
= Object-Oriented File System Virtualisation = For 2007, the PSF would like to concentrate on projects that
advance PSF projects (CPython and its documentation,
Jython and its documentation, the Python web site).
The following pages list some ideas:
Line 58: Line 79:
(Adam Kerz)  * SimpleTodo -- very small projects.
 * ["CodingProjectIdeas/PythonCore"] -- ideas for the CPython interpreter.
 * ["CodingProjectIdeas/StandardLibrary"]
 * JythonProjects
Line 60: Line 84:
Create an object oriented model of a file system in Python that can be used to interface many different resource types (with appropriate implementations). == Previous years ==
Line 62: Line 86:
Mentor: Trent Mick.

= Wax GUI for Python =

(Abhishek Reddy)


Wax requires work on four broad fronts. Firstly, support for several
basic controls need to be added, some of which are listed
above. Secondly, the design of the whole module has to be reviewed,
particularly focusing on the initialisation. Thirdly, there are
teething problems with passing data between Wax and wxPython that must
be looked at. Fourthly, documentation, presently lacking, needs to be
written.

Mentor: Hans Nowak

= PyTrails =

(Jennifer Dozar)

I'm working on an extensible opensource engine for implementing
trail-style games such as Oregon Trail or Amazon Trail. The primary
goal is to produce a quality edutainment title that can be used free
of cost. The secondary goal is to make it easy for other edutainment
trail games to be created. PyTrails will be Python based and uses
PyGame. The engine will allow following a branching map including
making stops to rest, hunt, or trade. Additional choices such as
shopping and fording rivers may be available at special points. Each
of these activities will be replacable in other trail games as to
allow for maximum flexibility.

Mentors: Cameron Laird, Andrew Kuchling

= mmpy -- A garbage collection tool kit in Python =

(Carl Friedrich Bolz)

The project aims at producing a framework for writing and
evaluating garbage collectors in Python. The interfaces to
the low level memory and to the object model will be general
enough to make it usable for a wide range of projects in
need for garbage collection as well as for teaching and
research purposes. It will be designed with flexibility and
modularity in mind to encourage component reuse. It aims a
being directly useful for the PyPy project and translatable
by its translation tools.


Mentors: Samuele Pedroni, Armin Rigo

= Python to C++ translator =

(Mark Dufour)

As part of my Master's Thesis, I am working on a
Python-to-C++ compilation system.

Mentors: Jeremy Hylton, Brett Cannon

= Mailbox modification =

(Gregory K. Johnson)

I propose to rewrite the Python library's mailbox module to support
mailbox modification. I would extend the module's API (e.g., mailboxes
would sport dictionary-like mapping) and enhance certain existing
functionality (e.g., message objects would maintain
mailbox-format-specific attributes). Full backward compatibility would
be maintained.

Mentor: Andrew Kuchling

= Memory Profiler =

(Nick Smallbone)

I would like to apply to work over the summer on a Python memory
profiler, as listed at CodingProjectIdeas.

To see how much work is involved in this, I've put together a
prototype, which tries to enumerate all objects from a root,
calculating the size of each object it finds.

Mentors: Michael Hudson, Jeremy Hylton

= Python Bayesian Network Toolbox =

(Elliot Cohen)

Understanding about Bayesian Belief Networks and use of them is
becoming more and more widespread. As understanding develops and
spreads out of the research community, there is greater and greater
need for a simple to use efficient open source Bayesian Network
Toolbox. Bayesian Networks have been used to study a wide array of
different areas including, ecological systems, medical diagnoses and
financial modeling, among others. Currently, tools to define and use
Bayesian Networks are limited to expensive closed source libraries or
open source libraries designed for too specific a domain. One package
that does support many varieties of Bayesian Networks is Kevin
Murphy's Full BNT, which supports both discrete and continuous
probability distributions in static and dynamic Bayesian Networks.

Mentor: James Tauber

= asyncIO =

(Vladimir Sukhoy)

The proposed goal is to bring cross-platform proactive I/O
capabilities to Python. That will enable whole new style of
application development with Python in cases when I/O is a bottleneck.

Mentor: Mark Hammond?


= Interactive Python Notebook =

(Toni Alatalo)

See <http://ipython.scipy.org/google_soc/ipnb_google_soc.pdf>.

Mentor: Fernando Perez

= Porting _sre.c and arraymodule.c to Python =

(Niklaus Haldimann)

I would like to create a port of the standard library modules "_sre" and "array" to pure Python. This will benefit alternative Python implementations like PyPy, Jython and IronPython. These projects all have to provide their own implementations of standard library modules written in C if they're not available in pure Python.

Mentors: Armin Rigo, Samuele Pedroni

= Python Profile Replacement Project =

(Floris Bruynooghe)

Idea from ProfileReplacementProject page.

The current profiler is not free according to the DFSG (Debian Free
Software Guidelines) and has been taken out of the main Debian
distribution (bug #293932, http://bugs.debian.org/293932). This
affects many users as the profiler is integrated into ipython for
example[1]. Patches for these programs to run without the profiler
have been incorporated, but this is only patchwork and ipython or one
lost previously standard functionality.

Mentors: Brett Cannon

= Wax =

(Jason Gedge)

This project consists of updating the Wax library for Python. Code
will be updated, or even added, to further develop the Wax
library. Also, a primary focus will be that of documentation, which
Wax currently lacks.

Mentors: Hans Nowak

= Data Serving/Collection Framework in Python/WSGI =

(Ho Chun Wei)

A framework based on bulk data serving/collection via the
internet. Bulk data are in the form of files that could easily be
several hundred MB (not surveys or simple POST data).

The client has a file repository that it wishes to sync to the server
(a WSGI application). This server should be able to facilitate
transfer via a number of protocols, including HTTP file transfer, HTTP
form upload, FTP, Email.

This project is aimed not at yet another ad-hoc file transfer or p2p
file-sharing program but as a persistent production setup for
transferring data from data collection sites/areas to a server,
possibly via internet through different methods to get through strict
organizational firewalls and web admins.

Mentors: Ian Bicking


= A Mathematica-like Notebook GUI for IPython =

(Tzanko Matev)

I propose to write a GUI for IPython resembling the
interfaces of the computer algebra applications Mathematica
and Maple.

Mentor: Fernando Perez
 * ["SummerOfCode/2005"]
 * ["SummerOfCode/2006"]

This page coordinates the [http://code.google.com/soc/ Google "Summer of Code"] projects involving Python and mentored by the Python Software Foundation (PSF).

Discussion about any Python-related SoC topic should take place on [http://mail.python.org/mailman/listinfo/soc2006 the soc2006 mailing list].

Students: How to submit a proposal

[http://code.google.com/soc/student_signup.html Apply through Google's online form.]

[http://code.google.com/soc/student_step1.html Submit an application.]

The Drupal folks have some good information for students on [http://drupal.org/node/59037 how to write a SoC application]

Here is Google's [http://code.google.com/soc/studentfaq.html Student FAQ].

Tips on writing your proposal

Be detailed. Don't say "I want to improve Python's support of XYZ", because that's vague, making it difficult to assess the project's feasibility or the time required. Exactly what changes would you make to improve XYZ support?

Compare with alternative projects. If your project will do task XYZ, look at other existing projects that perform the same task and explain how yours is different or better. (Or you can write a proposal to finish an existing project instead.)

Try to provide a rough timeline. How much time would each change take (a day, a week, six weeks)? What intermediate milestones will there be? (e.g. for a game, you might get an initial graphic display in week 1, write a parser for level definitions in week 2, write a level editor in weeks 3 and 4, etc.)

Get feedback. Post the proposal to a relevant mailing list and ask for comments. Post the proposal to your weblog and see what people think.

Describe your experience. Why are you a good person to work on this project? What skills/interests/knowledge do you have that are applicable?

Suggest a mentor. If you know a developer who would be a good mentor for your project, contact him/her and ask if they're interested. In 2005 and 2006, some interesting projects went unfunded because there was no one in the pool of mentors who felt capable of handling them.

Looking at the list of PSF mentors can help you craft your proposal to match their interests.

  • ["SummerOfCode/Mentors"]

Tips on participating

  1. Do not overbook yourself. Working on your project should be your main activity for the entire summer.
  2. Participate in the developer community by joining python-dev, jython-dev, or whatever mailing list is appropriate.
  3. If you get stuck, ask for help instead of silently struggling. You can ask your mentor for help, or post a question to the development mailing list.
  4. You must provide weekly status reports.
  5. You will be expected to learn how to use SVN.

Mentors: How to apply

The mentor's responsibility is to ensure the student makes progress. This could entail coaching them, providing motivation, making sure they aren't stuck, answering technical questions, or pointing the student to the proper resources. Mentors should expect to get a weekly status report from their students, and should bug students who are not communicating.

However, the mentor is not expected to do work for the student.

Mentoring duties are expected to take a couple of hours per week.

[http://code.google.com/soc/mentor_step1.html Apply through Google's online form.]

Project ideas

For 2007, the PSF would like to concentrate on projects that advance PSF projects (CPython and its documentation, Jython and its documentation, the Python web site). The following pages list some ideas:

Previous years

  • ["SummerOfCode/2005"]
  • ["SummerOfCode/2006"]

SummerOfCode/2007 (last edited 2008-11-15 14:00:01 by localhost)

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