|
Size: 11236
Comment:
|
Size: 1400
Comment: Adding DrProject idea
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| = Python Implementation of the Data Access Protocol = | These are the [http://code.google.com/soc/ Google "Summer of Code"] projects involving Python. |
| Line 3: | Line 3: |
| (Roberto Antonio Ferreira De Almeida) | For information on the accepted projects for 2005, see ["SummerOfCode/2005"]. |
| 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. |
= How to apply as a mentor = |
| Line 20: | Line 7: |
| Mentor: Paul DuBois. | Apply through Google's online form. (Not up yet.) |
| Line 22: | Line 9: |
| * [http://code.google.com/soc/mentorfaq.html Mentor FAQ] | |
| Line 23: | Line 11: |
| = Interactive Comments & Annotation for the Python Standard Reference = | = How to submit a proposal = |
| Line 25: | Line 13: |
| (Brian Beck) | * [http://code.google.com/soc/studentfaq.html Student FAQ] |
| Line 27: | Line 15: |
| 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. |
= Proposal ideas = |
| Line 31: | Line 17: |
| Mentors: Ian Bicking, Andrew Kuchling | The following ideas are just suggestions. You're free to invent your own ideas, or to use their suggestions as starting points. |
| Line 33: | Line 19: |
| = Bitten: A Python framework for collecting software metrics from automated builds = | * Some ideas to help get you started: look at the SimpleTodo and CodingProjectIdeas pages. * Revive restricted Python -- inspired by a recent thread on the py3k list. * Create a bunch of modules like what Squeak has for 3D modeling, events etc. (the exact list may be somewhat different, I haven't researched this in any depth). This is inspired by a recommendation from Alan Kay made at the Shuttleworth workshop. * Add a web-based admin interface and/or user-oriented views to [http://www.third-bit.com/drproject DrProject], a lightweight project management portal intended for use in software engineering courses. |
| Line 35: | Line 27: |
| (Christopher Lenz) mentors: gregwilson; trentm | = Bitten: A Python framework for collecting software metrics from automated builds = Today's auto |
= Accepted proposals = |
| Line 38: | Line 29: |
| 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. | Note: if a project is listed as having two mentors, the first mentor listed is the ''primary'' mentor, and the second one is the ''back-up'' mentor. |
| Line 40: | Line 31: |
| Mentors: Greg Wilson, Trent Mick. = A Program Visualization Tool = (Tero Kuusela) 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. Mentor: David Ascher. = Object-Oriented File System Virtualisation = (Adam Kerz) Create an object oriented model of a file system in Python that can be used to interface many different resource types (with appropriate implementations). 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 = Efficiently Analysing Data Polymorphism and Deducing Generics in Shedskin = (Mark Dufour) As part of my Master's Thesis, I am working on a Python-to-C++ compilation system, called Shedskin. Currently, it performs static type inference based on two techniques. The Cartesian Product Algorithm is used to handle parametric polymorphism (calling functions with different combinations of argument types); single-level class duplication, or 1CFA, is employed to handle data polymorphism (mostly polymorphic containers, such as list; in 1CFA, each allocation site gets its own class type, so we can analyze these (somewhat) precisely.) Run-time checks such as 'isinstance' are considered during inference. Further, short tuples are analyzed internally, which of course is especially important in case of Python. Based on the statically determined type information, the compiler currently performs stack- and static pre-allocation (using a simple escape analysis, and the static call graph respectively) and unboxing. Further, it generates polymorphic inline caches or virtual calls when a singleton type set cannot be deduced. Single-level class duplication is imprecise, because it only duplicates class types once for each allocation site, and allocation sites may be duplicated during analysis (as CPA possibly creates many templates for each function.) Extending it to N levels, or NCFA, would make the analysis terribly exponential and still not precise for deep polymorphism. For the summer of code, my main goal will be to efficiently and precisely handle data polymorphism up to arbitrary depths. I am currently looking into an iterative technique developed by John Plevyak. (Tiejun & Wang's technique is incomprehensible, and I don't see how the method used in Starkiller would work.) My other large goal will be to generate generics of appreciable complexity, based on the inferred types, i.e. to determine whether types may be uniformly parameterized, and to generate class and function templates. Finally, I will integrate an existing C++ garbage collector into the run-time system in order to clean up objects that could not be stack- or statically pre-allocated. Mentors: Jeremy Hylton, Brett Cannon = Mailbox modification = (Gregory K. Johnson) I intend to rewrite the Python library's mailbox module to support mailbox modification. I will extend the module's API (e.g., mailboxes will sport dictionary-like mapping) and enhance certain existing functionality (e.g., message objects will maintain mailbox-format-specific attributes). Full backward compatibility will 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 |
* None yet. |
These are the [http://code.google.com/soc/ Google "Summer of Code"] projects involving Python.
For information on the accepted projects for 2005, see ["SummerOfCode/2005"].
How to apply as a mentor
Apply through Google's online form. (Not up yet.)
[http://code.google.com/soc/mentorfaq.html Mentor FAQ]
How to submit a proposal
[http://code.google.com/soc/studentfaq.html Student FAQ]
Proposal ideas
The following ideas are just suggestions. You're free to invent your own ideas, or to use their suggestions as starting points.
Some ideas to help get you started: look at the SimpleTodo and CodingProjectIdeas pages.
- Revive restricted Python -- inspired by a recent thread on the py3k list.
- Create a bunch of modules like what Squeak has for 3D modeling, events etc. (the exact list may be somewhat different, I haven't researched this in any depth). This is inspired by a recommendation from Alan Kay made at the Shuttleworth workshop.
Add a web-based admin interface and/or user-oriented views to [http://www.third-bit.com/drproject DrProject], a lightweight project management portal intended for use in software engineering courses.
Accepted proposals
Note: if a project is listed as having two mentors, the first mentor listed is the primary mentor, and the second one is the back-up mentor.
- None yet.