Here's the text, for those of you not signed up with Google. If you ARE
signed up as a mentor, please use their application to comment, as that
allows me to revise the application! I have until the end of tomorrow
to edit the application before it is frozen; if you have any feedback,
please provide it promptly, thanks.
--------------------------------
Name: Walter Mundt
E-Mail: emage@spamcop.net
Mentoring Organization: Subversion
Project: Improving the Python Bindings
Description From http://subversion.tigris.org/project_tasks.html:
The Subversion Python bindings are currently incomplete in the
functionality that they expose (for one example see the above issue).
Furthermore, the Python bindings are currently extremely unpythonic in
their structure, and could do with a layer of python code to make them
so. The bindings should first be brought up to date and all
functionnalities completely implemented, and second be wrapped in a set
of Python classes implementing an interface more friendly to python
developers.
General Design:
The design will, in general, follow that of the Ruby bindings: add a
thin layer of Python code on top of the generated Swig bindings to
provide more 'Pythonic' features and behaviors to the library. Wherever
a Python-native data type is a logical fit, attempt to allow and
encourage its use. The bindings should at least be compatible with
Python 2.3 and up; 2.4-specific constructs are to be avoided. If there
is sufficient demand, Python 2.2 compatibility might be targeted.
Notes:
* All patches adding new Python APIs are to include thorough
Python docstrings as documentation, plus some separate
overview/introductory material where the mentor(s) deem it
appropriate.
* Patches are also to include test client code; where possible
this code should exercise the majority of the Python interface,
although trade-offs between interface complteness and testedness
may need to be made due to the limited time frame involved.
Deliverables, in approximate order of implementation:
* Patch to work around inability to set baton/callback pairs in
Python. This may be a bit messy, but the idea is to wrap all
uses of the SWIG-level Python interface when coding up the
pure-Python usability-enhancement layer.
* Patches to add a object-oriented Python API for the various
Subversion component libraries, in approximately this order,
plus whatever functionality in 'Core' is needed at each level:
* Client
* Working copy, delta
* Repository Access
* Repository
* Filesystem
Interest/Motivation:
As a user of both Python and Subversion, I very much like the idea of
being able to easily interface with Subversion from one of my languages
of choice. While I've not personally written Python binding libraries
before, I've examinied and understood a few examples, and I know both C
and Python well enough to have a good grasp of what is going on between
the two.
General Background/Bio:
I am a computer science student at the University of Central Florida,
and I recently competed in the finals for the ACM International
Collegiate Programming Competition. I'm currently also working for a
defense contractor, writing Java and the occasional Python/misc. code.
I also have work experience in C/C++ and Perl, and knowledge Unix shell
scripting and a smattering of other languages/tools.
Post-SoC Intent:
If I am selected to do this work for the Summer Of Code, I also intend
to commit, at a minimum, to maintaining the results for a least 6-8
months after the Summer ends, and longer if it seems necessary to make
the end result usable and maintainable. I may further decide to
continue active development or to even expand my interest in Subversion
development if we enjoy working together enough.
--
Walter Mundt
emage@spamcop.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 8 02:19:18 2006