On 5/7/06, Walter Mundt <emage@spamcop.net> wrote:
> 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.
Walter, you have a very clear understanding of what needs to be done
to improve the Python bindings. Great proposal!
> 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.
+1. The Ruby bindings are a great model.
> 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.
+1. I'm happy to only support Python 2.2 on a best-effort basis.
> 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.
+1! Currently, the documentation for the Python bindings is sorely
lacking. Any work in this area is much appreciated.
> * 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.
No problem! I understand there are time constraints.
> 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.
Could you explain how this works? (No need to update your proposal
with this info -- just send it to the mailing list)
> * 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
If you can write rock solid, well-tested, Pythonic, object-oriented
and fully documented bindings for just the first of those five
libraries, I'll be as happy as can be. If you can deliver all five,
you'll be our hero.
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.
In any case, I'll be happy to mentor your application, and I'll notate
as such on code.google.com.
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon May 8 20:04:00 2006