You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Walter Mundt <em...@spamcop.net> on 2006/05/02 08:30:05 UTC
SoC proposal: "pythonificating the python bindings"
(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
Re: SoC proposal: "pythonificating the python bindings"
Posted by Walter Mundt <em...@spamcop.net>.
David James wrote:
> For sure! The link on the issues page is just an example. I don't
> think that 'single example' is representative at all of what needs to
> be done.
>
> What I'd really like to see is a general clean up of the Python
> bindings to have a more usable class structure, similar to the Ruby
> bindings. It'd be great if you could just type:
That's the idea, of course. What I'm wondering is whether there are
many (more) known things that you currently _can't do_ in Python, no
matter how clunky and disgusting you're willing to make the code. I
understand fairly well the scope of adding an extra Python layer do do
syntax like you've described, and that is definitely going in the
proposal. However, if the actual SWIG-level bindings have to be fixed
in multiple non-trivial ways before I can even start on that, it's going
to limit the amount of time I can spend actually 'pythonificating'.
Apologies if I wasn't clear on that.
-Walter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SoC proposal: "pythonificating the python bindings"
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On 5/2/06, Blair Zajac <bl...@orcaware.com> wrote:
> It looks like there already exists a Pythonic svn interface.
pysvn uses custom C++ bindings. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SoC proposal: "pythonificating the python bindings"
Posted by David James <dj...@collab.net>.
On 5/2/06, Blair Zajac <bl...@orcaware.com> wrote:
> David James wrote:
> > On 5/2/06, Walter Mundt <em...@spamcop.net> wrote:
> >> 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.)
> > For sure! The link on the issues page is just an example. I don't
> > think that 'single example' is representative at all of what needs to
> > be done.
> >
> > What I'd really like to see is a general clean up of the Python
> > bindings to have a more usable class structure, similar to the Ruby
> > bindings. It'd be great if you could just type:
>
> How does this proposed work relate to the pysvn project:
>
> http://pysvn.tigris.org/
>
> It looks like there already exists a Pythonic svn interface.
>
> Does that provide many of the features already discussed here?
PySVN does offer a simple (and documented!) interface to much of the
Subversion command-line client functionality, but it doesn't provide
extensive coverage of Subversion's APIs. Further, PySVN doesn't
integrate with our Python bindings at all, but instead bypasses them
and interacts directly with the C API.
On the other hand, the Subversion Python bindings *do* have pretty
comprehensive coverage, but very little of the available functionality
is documented or easy to use. For a summer of code project, I'd like
to see us make our Python bindings be as easy to use as PySVN or our
very own Ruby bindings.
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
Re: SoC proposal: "pythonificating the python bindings"
Posted by Blair Zajac <bl...@orcaware.com>.
David James wrote:
> On 5/2/06, Walter Mundt <em...@spamcop.net> wrote:
>
>> 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.)
>
>
> For sure! The link on the issues page is just an example. I don't
> think that 'single example' is representative at all of what needs to
> be done.
>
> What I'd really like to see is a general clean up of the Python
> bindings to have a more usable class structure, similar to the Ruby
> bindings. It'd be great if you could just type:
How does this proposed work relate to the pysvn project:
http://pysvn.tigris.org/
It looks like there already exists a Pythonic svn interface.
Does that provide many of the features already discussed here?
Regards,
Blair
--
Blair Zajac, Ph.D.
<bl...@orcaware.com>
Subversion training, consulting and support
http://www.orcaware.com/svn/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SoC proposal: "pythonificating the python bindings"
Posted by David James <dj...@collab.net>.
On 5/2/06, Walter Mundt <em...@spamcop.net> wrote:
> 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.)
For sure! The link on the issues page is just an example. I don't
think that 'single example' is representative at all of what needs to
be done.
What I'd really like to see is a general clean up of the Python
bindings to have a more usable class structure, similar to the Ruby
bindings. It'd be great if you could just type:
import svn.client
repo = svn.client.Client('http://svn.collab.net/svn/trunk')
print repo.ls()
repo.mkdir("some-directory", "some commit message")
.. or ...
repo = svn.client.Client('/some/path')
repo.add('file.txt')
repo.commit('commit message')
> 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.
If you're looking for examples of nice interfaces to Subversion, take
a look at the Ruby bindings. Last summer, Kouhei Sutou implemented
this fantastic, easy to use interface in Ruby. If you could help write
a similar interface for the Python bindings, you'd be a star. Even if
you only have time to finish the 'client' library (and don't have time
for the 'wc', 'repos', 'fs', or other libraries), that'd be a killer
Summer of Code project.
Writing a complete, object-oriented interface for just the client
library would be a great Summer of Code project. To see an example of
what we're looking for, take a look at Subversion's Ruby bindings for
the client library:
http://svn.collab.net/repos/svn/trunk/subversion/bindings/swig/ruby/svn/client.rb
If there's more than one student out there who wants to work on the
Python bindings, we could split up the work by assigning each student
a different library. To see a list of the libraries supported by Ruby,
check out http://svn.collab.net/repos/svn/trunk/subversion/bindings/swig/ruby/svn
> 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?
Last summer, I upgraded the Python bindings to support automatic
memory management -- so there's no need to supply pools anymore. If
you're looking for a performance boost, or want to have more
fine-grained control, you can still supply pools, but Subversion will
manage memory automatically by default.
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
Re: SoC proposal: "pythonificating the python bindings"
Posted by Walter Mundt <em...@spamcop.net>.
Daniel Berlin wrote:
> While it's early, and I haven't thought of all possible problems in this
> approach (noting at the same time that it is more or less what we do
> right now in C explicitly), the main one that pops out to me is the
> python version requirement (IE decorators are 2.4+).
Not really a problem. You see, the nice @decorator _syntax_ is Python
2.4-dependent, but actually implementing a decorator is just writing a
callable, and you can still use the clunky f = decorator(decparams)(f)
syntax to apply decorators in Python <= 2.3.
-Walter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SoC proposal: "pythonificating the python bindings"
Posted by Daniel Berlin <db...@dberlin.org>.
> 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?
>
While it's early, and I haven't thought of all possible problems in this
approach (noting at the same time that it is more or less what we do
right now in C explicitly), the main one that pops out to me is the
python version requirement (IE decorators are 2.4+).
I'm sure you can work around this with explicit proxying or something.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org