(In case you're wondering, that particular language-mailing isn't my
fauly; it's a quote from Dave's message in the SoC thread on this list.)
I'm interested in submitting an application to work on this idea for the
Google Summer of Code. I already have a pretty good idea of how to
handle the design, but I wanted to check in on the list to see if anyone
has any pointers or gotchas for me before I start putting together my
proposal.
Are there any issues with the Python bindings that will need fixing
other than the one linked on the ideas page? (I would consider any
other instance of the can't-assign-to-a-function-pointer problem part of
that issue, so what I'm asking for is any known problems _not_ stemming
from that.)
Any specific conditions or guidelines by which I should set up the
Python class structure? I understand the general idea of Python-ifying
C interfaces, and have looked at the beginnings of the work done in
trunk for libsvn_core.
One specific Python/APR divide I'm looking at is the APR "pool"
mechanism. Passing pools about is very tedious and verbose. I
understand the logic behind it, though! One possible API simplification
that might help would be to have all pool parameters passed by keyword
in Python, and then make a Python function decorator that adds a pool=
keyword argument to a function, and automatically pulls its value from
the caller's namespace if it isn't provided explicitly. Then, you could
have the desired semantics for regular usage "by default", and
explicitly create and manage loop subpools where necessary. Thoughts?
-Walter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 2 10:30:30 2006