David James wrote:
> Walter, could you update your proposal with specific dates (and time
> estimates, in hours) for each of your objectives? I understand it's
> hard to predict progress before you get started, but it'd rock if we
> had some ballpark estimates so that we can measure our progress.
Updated now. The estimates are based in part on the amount of Ruby code
required for those bindings, and, as is mentioned in the application,
are very rough. I have nearly zero experience in actually scheduling my
development efforts, so feel free to tell me I'm way off base, and/or
provide pointers on how to to it better.
Application as submitted follows, as before:
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
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; 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
Estimated Time Requirements: (note: these are _very_ rough)
* Baton/Callback patch: 5 hours
* Client: 70 hours
* Delta, W.C.: 45 hours
* Repository Access: 25 hours
* Repository: 30 hours
* Filesystem: 30 hours
Estimated Schedule (deliberately aggressive):
* May 23: Baton/Callback patch
* May 24-Jun 04: Client
* Jun 05-14: Delta, W.C.
* Jun 15-19: Repository Access
* Jun 20-26: Repository
* Jun 27-Jul 03: Filesystem
* Remainder: Additional regression tests, bug fixes, refinement
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 Tue May 9 03:25:11 2006