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 functionalities 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; this code should exercise the majority of the Python interface.

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 these Subversion component libraries, in approximately this order, plus whatever functionality in 'Core' is needed at each level:
  • Client
  • Working copy, delta
• Developer documentation providing overviews of the most common use cases for the libraries covered, at a higher level than would be appropriate for inline docstrings.

Estimated Time Requirements: (note: still rough)

• Baton/Callback patch: 8 hours
• Client: 120 hours
• Delta: 60 hours
• Working Copy: 60 hours

Estimated Schedule:

• May 23: Baton/Callback patch
• May 24-Jun 21: Client
• Jun 14-28: Delta
• Jun 29-Jul 13: Working Copy
• Jul 14-Aug 21: Developer documentation, refinement, performance analysis/optimization, test coverage check, bugfixes as needed

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.