Version 21 (modified by jarrod.millman, 3 years ago)

--

The SciPy? GSoC projects are run under the umbrella of the PSF. The PSF will be heavily weighting Py3K projects this year (see the following email).

----- Forwarded message from "C. Titus Brown" -----

Hi all,

it's that time of year again, and Google has decided to run the Google
Summer of Code again!

 http://groups.google.com/group/google-summer-of-code-discuss/browse_thread/thread/d839c0b02ac15b3f

 http://socghop.appspot.com/

Arc Riley has stepped up to run it for the PSF again this year, and I'm
backstopping him.  If you are interested in mentoring or kibbitzing on those
who are, please sign up for the soc2010-mentors mailing list here,

 http://mail.python.org/mailman/listinfo/soc2010-mentors

This year we're proposing to solicit and prioritize applications for
Python 3.x -- 3K tools, porting old projects, etc.  Python 2.x projects
will be a distinct second.  There will be no "core" category this year,
although obviously if someone on one of the core teams wants to push a
project it'll help!

If you have an idea for a project, please send it to the -mentors list and add
it to the wiki at

  http://wiki.python.org/moin/SummerOfCode/2010

We're also going to change a few things up to make it more useful to the PSF.
Specifically,

 - the foundation is going to *require* 1 blog post/wk from each student.

 - we're going to hire an administrative assistant to monitor the students.

 - the student application process will be a bit more rigorous and job-app
  like; the Django SF has been doing this for at least one round and they
  claim that it results in much better and more serious students.

 - we'll be focusing on student quality more than on project egalitarianism.
  If project X can recruit three fantastic students to one fantastic and one
  mediocre student for project Y, then project X gets three and project Y
  gets one.

The hope is that this will make the GSoC much more useful for Python than it
has been in the past.

Arc will be posting something to the www.python.org site and python-announce
soon, too.

Followups to soc2010-mentors.

cheers,
--titus

----- End forwarded message -----

Given the focus on Py3K-related projects, the most likely proposals to be accepted will be ones that continue work on the Py3K port of NumPy? or propose to port SciPy?, matplotlib, or ipython to Py3K.

Summer of Code 2010 Ideas

Ideas with significant existing momentum

  • Port SciPy to Python 3.0 (or continue finishing up the porting of NumPy)
    • Improve numpy.f2py test coverage and fix any issues that crop up on Python 3.
    • Port Scipy to Python 3
      • Set up a build framework that uses 2to3 (see e.g. how it is done in Numpy)
      • After that, modify Scipy so that it works both on Python 2 and Python 3 -- this can be done one submodule at a time, so the work can be partitioned in manageable pieces. Some submodules will be more work than others.
      • Knowledge of C is required in porting some of the submodules. There are, however, also pure-Python submodules.
      • Some information on: changes made in porting Numpy
  • datetime types - see the NEP and recent SVN versions of NumPy
  • Continue work on Fwrap started by Kurt Smith in GSoC2009
  • integrate Jonathan Taylor's statistical models into scipy.stats - see scikits.statsmodels (Skipper Seabold, GSoC2009), current task for this is improving scikits.statsmodels

Partially recycled from previous years' project ideas.

  • improve datasource and integrate it into all the numpy/scipy io http://projects.scipy.org/scipy/numpy/browser/trunk/numpy/lib/_datasource.py
  • clean up, refactor scipy package structure: scipy.lib, scipy.misc, scipy.stsci (already gone) - is this still relevant? no discussion on it
  • modernize, clean-up scipy.weave, integrate fast-vectorize
  • Statistics Cleanup
  • scipy.ndimage: Rewrite in Python where possible, port to Cython elsewhere. Decide on a consistent coordinate framework. As a bonus, fix boundary issues.
    • Leverage patches from CellProfiler developers for this, see e.g. patches with ticket #945
  • Automatic Differentiation - there are existing implementations and work in progress (algopy, openopt)