You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Lele Gaifax <le...@nautilus.homeip.net> on 2004/04/18 17:32:46 UTC
Python bindings
Hi all,
I spent some time studying Pyrex_, and wonder if anybody considered it
for a next-generation Python bindings implementation.
The toolset lets you wrap in a extremely pythonic way an external
library, without the swig hassle.
For example, consider the following scripts, that is all what's needed
to wrap the apr pool within a Python object (class!!).
The first is the "declaration", the interface of the module. Note the
"Cdef"s, that expose **just** the needed functionalities::
cdef extern from "apr_general.h":
int apr_initialize()
void apr_terminate()
cdef extern from "apr_pools.h":
ctypedef struct apr_pool_t
int apr_pool_create(apr_pool_t **pool, apr_pool_t *parent)
cdef class Pool:
cdef apr_pool_t *pool
The second, even simpler one, is the implementation. Note: here we
are implementing what will become a CPython class, using an almost
Python syntax, with light C tweaks::
cdef class Pool:
def __new__(self, Pool parent = None):
if parent:
apr_pool_create(&self.pool, parent.pool)
else:
apr_pool_create(&self.pool, NULL)
def initialize():
apr_initialize()
def terminate():
apr_terminate()
The third, the usual Python setup::
from distutils.core import setup
from distutils.extension import Extension
from Pyrex.Distutils import build_ext
setup(
name = 'svn',
ext_modules=[
Extension("apr", ["apr.pyx"],
include_dirs=["/usr/include/apr-0"],
libraries=["apr-0"]),
],
cmdclass = {'build_ext': build_ext}
)
Finally, the Makefile recipe::
all:
python Setup.py build_ext --inplace
clean:
rm -f *.c *.o *.so *~ core
rm -rf build
This allows me to::
$ make
python Setup.py build_ext --inplace
running build_ext
building 'apr' extension
creating build
creating build/temp.linux-i686-2.3
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall \
-Wstrict-prototypes -fPIC -I/usr/include/apr-0 \
-I/usr/include/python2.3 -c apr.c -o build/temp.linux-i686-2.3/apr.o
apr.c: In function `__pyx_f_3apr_initialize':
apr.c:99: warning: label `__pyx_L1' defined but not used
....
gcc -pthread -shared build/temp.linux-i686-2.3/apr.o -lapr-0 -o apr.so
Then with a "but-is-it-for-real-face-with-a-?-nose::
$ ls -lrt
totale 73
-rw-r--r-- 1 lele lele 92 1 apr 03:44 Makefile
-rw-r--r-- 1 lele lele 322 1 apr 03:50 Setup.py
-rw-rw-r-- 1 lele lele 513 1 apr 04:21 apr.pyx
-rw-rw-r-- 1 lele lele 501 1 apr 04:21 apr.pxd
-rw-rw-r-- 1 lele lele 11865 18 apr 19:18 apr.c
drwxrwxr-x 3 lele lele 1024 18 apr 19:18 build
-rwxrwxr-x 1 lele lele 56241 18 apr 19:18 apr.so
And finally, ashtonished::
$ python
Python 2.3.3 (#2, Feb 24 2004, 09:29:20)
[GCC 3.3.3 (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import apr
>>> apr.initialize()
>>> pool = apr.Pool()
>>> print pool
<apr.Pool object at 0x401d6050>
>>> subpool = apr.Pool(pool)
>>> print subpool
<apr.Pool object at 0x401d6060>
While it's clear that this would benefit only the Python side of the
bindings, I think that the new layer would be more powerful and at the
same time much more manageable.
What do you think?
ciao, lele.
.. _pyrex: http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Python bindings
Posted by Lele Gaifax <le...@nautilus.homeip.net>.
>>>>> "C" == C Michael Pilato <cm...@collab.net> writes:
C> I think the fact that would benefit only the Python side of
C> things is non-negligible downside. I also am not impressed
C> with claims that Python bindings that behave more Pythonic is
C> actually in and of itself a good thing.
That's an implementation choice: I maybe did not put the emphasis
right, it's the way you can express them that's more easy to understand,
fix, and complete.
C> I rather prefer the
C> system we have today, where the 'libsvn' module exposes our
C> public APIs in a form familiar to programmers of those APIs as
C> used in C or C++.
As my example showed, this is there almost for free.
C> And then we have the 'svn' module, which
C> (when I get some free time) will not merely wrap libsvn, but
C> will do so by creating more Pythonic objects (classes, etc.)
Once the underlying infrastructure is there, you mean. Too bad that
current bindings are not there yet, mainly for swig related thingies.
bye, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Python bindings
Posted by Daniel Rall <dl...@collab.net>.
Lele Gaifax wrote:
>>>>>>"Daniel" == Daniel L Rall <dl...@apache.org> writes:
>
> Daniel> C. Michael Pilato wrote: ...
> >> I think the fact that would benefit only the Python side of
> >> things is non-negligible downside.
> Daniel> ...
>
> Daniel> This is an important point. What about all the other
> Daniel> languages which SWIG supports? Sharing the core of the
> Daniel> bindings implementation across languages is powerful
> Daniel> reuse.
>
> As said, I second that. But when it comes to effectively weighting
> the hassle/benefit ratio, I think that other more specific ways of
> laying down the bindings would make them a) more powerfull and b)
> maintainable.
a) is debatable -- I might be convinced to agree, cmpilato perhaps not so much.
b) may be true, but the SWIG bindings are maintainable too.
> But even then, saying that there is an effective code sharing between
> the bindings is a bit optimistic: the hardest part /introduced/ by
> SWIG is that you need go and implement a wrapper for each object / for
> each language.
See a) -- this is debatable. In any case, the amount and type of code involved
with that layer borders is not overly significant.
> Yes, the /declarations/ are in common, but the hard
> work of dealing with arguments-transformer-function coupled with
> this-and-that function signature is a pita.
Yes.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Python bindings
Posted by Lele Gaifax <le...@nautilus.homeip.net>.
>>>>> "John" == John Peacock <jp...@rowman.com> writes:
John> I think you are mistaken about that; it would be just as
John> practical to create a Perl XS interface directly with
John> Subversion. But as I think Ben already asserted, we would
John> lose the shared knowledge gained by writing both Perl and
John> Python interfaces to the common SWIG framework.
Yes, I may be wrong. But still I do not see *why*, to code a binding,
I should lookup other sources other than SVN APIs.
John> Additionally, any of the other languages which work with
John> SWIG (Ruby, Tcl/TK, OCAML, and C#) could be used in the
John> future for Subversion, with far less effort than creating
John> direct API's.
This is true if you base your reasoning on the fact that the
language-specific part is far easier to write than the whole thing.
But this is clearly not the case, and I guess that all those languages
will follow a different path, if any, in the mid-term, as java is
doing right now.
John> Pyrex only helps Python and only those people who share your
John> view of how the API should be structured. You could just as
John> easily use the existing Python/SWIG bindings with an
John> additional layer of abstraction that fit your needs (much
John> like svk is doing with the Perl bindings).
No, it's completely a different matter. I'm not advocating yet another
layer above "something", as there is no need for it. Good CPython
based objects can definitively and directly cope with svn C internals,
without the crazyness of wrapping/unwrapping C structures every time
you feed them to/get them from whatever-language functions.
bye, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Python bindings
Posted by John Peacock <jp...@rowman.com>.
Lele Gaifax wrote:
> What I'm stating is that Perl and Python are different enough to
> warrant a different implementation of the bindings. I still think
> that the benefit of using swig with Python is very debatable, while I
> know that it's a must for practical reasons in the Perl world.
I think you are mistaken about that; it would be just as practical to create a
Perl XS interface directly with Subversion. But as I think Ben already
asserted, we would lose the shared knowledge gained by writing both Perl and
Python interfaces to the common SWIG framework. Additionally, any of the other
languages which work with SWIG (Ruby, Tcl/TK, OCAML, and C#) could be used in
the future for Subversion, with far less effort than creating direct API's.
Pyrex only helps Python and only those people who share your view of how the API
should be structured. You could just as easily use the existing Python/SWIG
bindings with an additional layer of abstraction that fit your needs (much like
svk is doing with the Perl bindings).
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Python bindings
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Apr 29, 2004 at 09:38:31AM +0200, Lele Gaifax wrote:
> >>>>> "Ben" == Ben Reser <be...@reser.org> writes:
>
> Ben> But until you do write a Pyrex binding set there really isn't
> Ben> anything to talk about further. Nobody on this list seems
> Ben> interested in doing it.
>
> Yes, and neither it seems a good place to talk about your baby, that's
> so perfect. Most of the time, you most are attacking either the place
> where one say something, or his capability to even discuss the matter.
>
> that's all, sorry for the noise.
It's unfortunate that your approach was "attacked" so much. I don't think
there was much call for it. Note that we have both SWIG-based and
manually-written Java bindings in the code today -- our bindings aren't
*all* swig. Under bindings/, we have swig/ and java/. I don't see any
reason why we couldn't also have a bindings/pyrex/.
That said: putting them into the standard distribution is an open
question. Barry's pysvn wasn't included because people didn't really agree
with the approach. I'd suggest that you put together the pyrex-based
bindings and propose them as an alternative set of bindings to live at
bindings/pyrex/. The discussion can then be very concrete about the merits
of putting them in the build, rather than abstract comments about the form
of implementation.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Python bindings
Posted by "C. Michael Pilato" <cm...@collab.net>.
Lele Gaifax <le...@nautilus.homeip.net> writes:
> C> I should also state that I know nothing of Pyrex.
>
> I'm even able to find all this funny, expecially when you insist that
> *I* do not know the matter enough to speak a different voice.
It wasn't meant to be funny. I'm *admitting* that I only know half
the story. I *invited* you to show me how Pyrex will make our lives
easier. Not with talk. Don't toss the freakin' user manual and tell
me read up on it. Life is busy. You want action? Send code.
> Sure, sorry again for the distraction. Won't spend another 0.01€ on
> sponsoring possible better ways of doing something, here.
For the record, the concerns you have voiced about SWIG and your
suggestion to use Pyrex are not a distraction. You seem to be aware
of both a technical hurdle and a possible solution to it.
The distraction is that instead of just submitting a patch for review
and possible inclusion, our list has been subject to what amounts to
holy war.
Let's move on.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Python bindings
Posted by Lele Gaifax <le...@nautilus.homeip.net>.
>>>>> "C" == C Michael Pilato <cm...@collab.net> writes:
C> Lele, I get the sense that you haven't actually tried to
C> implement Subversion bindings in Python.
That may come only from my inadeguate english knowledge, since as you
later state, I've already been there and found the glitches.
Whatever sense you may have, I do not think you are fair, here. For
the very last time, I ask you a little trust on my knowledge on
this. If you can't grant that, well, we just lost some time.
C> Step 2 even works, sorta. svn_config_get_config() returns a
C> SWIG pointer object that represents an apr_hash_t. Here's
C> where problems start to show up. See, for passing ctx into
C> interfaces that need it, this is perfect because so far it only
C> contains easily-mappable native types and SWIG pointer objects.
C> But that means we can't modify ctx.config as a dictionary
C> object from inside Python.
C> Of course, we instead write svn_config_get_config so that it
C> returns a Python dictionary instead of a SWIG apr_hash_t
C> pointer, we get the opposite effect -- modifying the returned
C> config in Python will be mindless, but any Subversion
C> interfaces expecting ctx.config to be an apr_hash_t will
C> instead find a Python dictionary object.
Ah, you see? Everything's done with SWIG end with this kind of
approach of having some (two, at least) functions that "convert"
internal data to/from the target language objects. For *each* new
datum type, you have then two functions *per* language, that do
whatever is needed.
With Pyrex, there's *no* need to follow that crazyness, as it allows
you to **easily** build native Python classes that wrap the needed
types, so that for example you can expose the *real* apr_hash as a
standard dictionary, gaining the two-way capability. Not having that,
is by all means a SWIG artifact.
C> I should also state that I know nothing of Pyrex.
I'm even able to find all this funny, expecially when you insist that
*I* do not know the matter enough to speak a different voice.
C> So go do the work (and by all means, please end this thread).
Sure, sorry again for the distraction. Won't spend another 0.01€ on
sponsoring possible better ways of doing something, here.
ciao, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Python bindings
Posted by "C. Michael Pilato" <cm...@collab.net>.
Lele Gaifax <le...@nautilus.homeip.net> writes:
> This is just an opinion, not supported by the reality. Can you show a
> single example of a library that was swigged into multiple language
> and provides good bindings?
I've only ever used the Python SWIG bindings, but in general, our
coverage is pretty good for functions used on either side of the RA
layer. I've written both server-side and client-side programs (even
wrote a basic GUI client) with few problems at all.
> Ben, *please*: a callback is as simple as calling whatever other
> function/method, it's not the bottleneck of the matter. And I do not
> see how the automatic garbage collection should make this more
> difficult. Python do little magics, and is perfectly prevedible. See
> where PyObjC has gone, and in that case, there are two distinct
> garbage collectors at work, not only Python's....
Lele, I get the sense that you haven't actually tried to implement
Subversion bindings in Python. That, or Pyrex is just a gift from
Heaven that is far more intelligent than I could ever imagine.
At least in the case of the SWIG bindings, there are a few real
bottlenecks:
- callbacks (of which there are a *bunch*)
- vtables (thankfully these are few)
- non-native datatypes used in read-write interfaces.
I imagine that anyone who has worked in any real way with the SWIG
bindings would has run into one of these problems. But generally
speaking, the rest of the work is cake, and SWIG (quite mightily) does
it for us.
> Well, do it, and you will recognize that, as simple as it can be for
> you, it will require you to tweak a method for every language, thus
> loosing the swig benefit you cited right from the beginning.
On this you are correct. The problem here is that we have this client
context structure which contains read-write complex datatypes. To set
the --no-autoprops stuff, you have to:
1. get an svn_client_ctx_t via svn_client_create_context()
2. set the configuration structure for that object by setting
ctx.config with svn_config_get_config().
3. get the actual config hash from that configuration structure with
svn_config_get_config()
4. finally, set the autoprops-related item in that hash.
Step 1, no sweat. Our bindings return a Python svn_client_ctx_t
object. That's great.
Step 2 even works, sorta. svn_config_get_config() returns a SWIG
pointer object that represents an apr_hash_t. Here's where problems
start to show up. See, for passing ctx into interfaces that need it,
this is perfect because so far it only contains easily-mappable native
types and SWIG pointer objects. But that means we can't modify
ctx.config as a dictionary object from inside Python.
Of course, we instead write svn_config_get_config so that it returns a
Python dictionary instead of a SWIG apr_hash_t pointer, we get the
opposite effect -- modifying the returned config in Python will be
mindless, but any Subversion interfaces expecting ctx.config to be an
apr_hash_t will instead find a Python dictionary object.
Steps 3 and 4 just further complicate things.
The only way I can think of to solve this problem completely involves,
as you said, writing custom tweaks for each language. And yes, that
loses the SWIG benefit. Of course, no one has claimed that SWIG can
gracefully solve all the problems automatically, and the fact of the
matter is that these kinds of painful scenarios are, I think, the
exception rather than the rule. So, please don't imply that because
you've found one of several cases where the elegance of SWIG falls
apart that the whole effort is a bust.
I should also state that I know nothing of Pyrex. I will be shocked
if it can deal with this gracefully and efficiently. The problem is
just a hard one.
> I did not ask you or anybody else to do that. You seem in confort with
> the current bindings sit, and this is very good for you. But do not
> waste your time trying convince everybody that the same should apply
> for them.
I too got the sense (originally) that you wished to ditch the SWIG
Python bindings and go with Pyrex. If that's not the case, and you
instead wanted to go the Pyrex route, go for it. Apparently unlike
Greg Stein, though, I frown heavily on the duplicated effort on the
Java front within our own tree. There should be, IMO, exactly one set
of official Subversion [language here] bindings. And we already have
one of these for Python that mostly works.
So go do the work (and by all means, please end this thread). If
Pyrex turns out to be a smokin' solution to the problem, present that
fact (with real code) to the community here. I mean, I'm not so bound
to the SWIG bindings that I wouldn't ditch them *in a heartbeat* for a
different approach that a) covered all the ground already covered by
our SWIG bindings, and b) promised to help us cover the remaining
ground more easily. You can even contact me privately about hosting a
Subversion repository for your efforts if you wish.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Python bindings
Posted by Lele Gaifax <le...@nautilus.homeip.net>.
>>>>> "Ben" == Ben Reser <be...@reser.org> writes:
Ben> SWIG is complicated becasue it is a complicated problem to
Ben> solve. Pyrex avoids a lot of that by:
No, there's nothing complicated in building a binding layer, at least
when compared to developing svn itself.
Ben> a) Requiring you to rewrite the interface specifications in
Ben> its syntax.
This is what SWIG force you to do too, and worst its syntax is
definitively neither Python, nor Perl, nor....
Ben> b) Only supporting one language.
Ben> The benefits of SWIG come about by solving the multiple
Ben> language problems in many cases and not forcing you to update
Ben> a separate interface for every change.
Ben> This doesn't always work in practice.
This is just an opinion, not supported by the reality. Can you show a
single example of a library that was swigged into multiple language
and provides good bindings?
Ben> Our code is littered with callbacks which are complicated to
Ben> make work and are language specific, especially when trying
Ben> to make the callback work right in a language with automatic
Ben> garbage collection. As a result, some changes do require
Ben> updates to the SWIG bindings. But these are the exception,
Ben> not the rule.
Ben, *please*: a callback is as simple as calling whatever other
function/method, it's not the bottleneck of the matter. And I do not
see how the automatic garbage collection should make this more
difficult. Python do little magics, and is perfectly prevedible. See
where PyObjC has gone, and in that case, there are two distinct
garbage collectors at work, not only Python's....
Ben> Regarding your specific complaint, I haven't looked at the
Ben> Python bindings, but I can't imagine what is so difficult
Ben> about --no-auto-props.
Well, do it, and you will recognize that, as simple as it can be for
you, it will require you to tweak a method for every language, thus
loosing the swig benefit you cited right from the beginning.
Ben> But to suggest that we should ditch SWIG now (with so much
Ben> work already done) and use Pyrex is similar (IMHO) to saying
Ben> "Subversion should have been written in Java," followed by a
Ben> great deal of debate about the merits of Java.
You evidently travised what I said.
Ben> None of it really matters, the point is unless the Java
Ben> people (or Pyrex people) are willing to spend the time to
Ben> reimplement what is already done with C (or SWIG).
I did not ask you or anybody else to do that. You seem in confort with
the current bindings sit, and this is very good for you. But do not
waste your time trying convince everybody that the same should apply
for them.
ciao, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Python bindings
Posted by Ben Reser <be...@reser.org>.
On Mon, May 10, 2004 at 03:40:42PM +0200, Lele Gaifax wrote:
> >>>>> "Greg" == Greg Stein <gs...@lyra.org> writes:
> Greg> Heh. I've been using the Python bindings for
> Greg> years. Literally.
>
> Yes, of course, and me too, through your code :)
>
> But that does not imply that one can actually use them to code say an
> equivalent of "svn add --no-auto-props somefile.py"... After few hours
> I gave up on swig, while it took *half* an hour to understand how to
> do the same for pysvn and contribute it back.
>
> That's the top priority for bindings, imho: assuming one master at
> least one of the two involved domains and is able to read/understand
> code/documentation of the other, he should definitively be in position
> of contribute to them. This is not currently so, as SWIG push in a
> third domain, almost as tricky and complicated as the sum of the other
> two. Pyrex promises just that, and even the C++ layer used by pysvn is
> closer.
SWIG is complicated becasue it is a complicated problem to solve. Pyrex
avoids a lot of that by:
a) Requiring you to rewrite the interface specifications in its syntax.
b) Only supporting one language.
The benefits of SWIG come about by solving the multiple language
problems in many cases and not forcing you to update a separate
interface for every change.
This doesn't always work in practice. Our code is littered with
callbacks which are complicated to make work and are language specific,
especially when trying to make the callback work right in a language
with automatic garbage collection. As a result, some changes do require
updates to the SWIG bindings. But these are the exception, not the
rule.
Regarding your specific complaint, I haven't looked at the Python
bindings, but I can't imagine what is so difficult about
--no-auto-props. You just modify the config on the context. I'm pretty
sure the SWIG Python bindings already support this. As do the Perl
bindings, though the Python bindings I believe are better at it. But
it's been a while since I messed with that stuff. My bet is
documentation of the bindings would go a long way towards resolving this
(and possibly other) complaints you have.
> Greg> But that said: I doubt that Ben was bashing the Python
> Greg> bindings in that way. Instead, I think each of you were just
> Greg> overreacting and should have stopped to take a breath :-)
Now I have no clue what this is talking about? I don't even know what I
said that could have possibly been construed as "bashing the Python
bindings." Nor do I know what way he thought I was. I wasn't bashing
any language or even any way of building bindings. If we were building
bindings from scratch today with no existing work done on them I might
find Pyrex a totally acceptable solution. But to suggest that we should
ditch SWIG now (with so much work already done) and use Pyrex is similar
(IMHO) to saying "Subversion should have been written in Java," followed
by a great deal of debate about the merits of Java. None of it really
matters, the point is unless the Java people (or Pyrex people) are
willing to spend the time to reimplement what is already done with C (or
SWIG). That has been my point all along.
> I concede that :) Sorry Ben for my possibly unweighted words. And
> thanks Greg for raising up my mood!-)
Appology accepted.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Python bindings
Posted by Lele Gaifax <le...@nautilus.homeip.net>.
>>>>> "Greg" == Greg Stein <gs...@lyra.org> writes:
>> You seem to think they are not even up to simple tasks.
Greg> Heh. I've been using the Python bindings for
Greg> years. Literally.
Yes, of course, and me too, through your code :)
But that does not imply that one can actually use them to code say an
equivalent of "svn add --no-auto-props somefile.py"... After few hours
I gave up on swig, while it took *half* an hour to understand how to
do the same for pysvn and contribute it back.
That's the top priority for bindings, imho: assuming one master at
least one of the two involved domains and is able to read/understand
code/documentation of the other, he should definitively be in position
of contribute to them. This is not currently so, as SWIG push in a
third domain, almost as tricky and complicated as the sum of the other
two. Pyrex promises just that, and even the C++ layer used by pysvn is
closer.
Greg> But that said: I doubt that Ben was bashing the Python
Greg> bindings in that way. Instead, I think each of you were just
Greg> overreacting and should have stopped to take a breath :-)
I concede that :) Sorry Ben for my possibly unweighted words. And
thanks Greg for raising up my mood!-)
ciao, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Python bindings
Posted by Greg Stein <gs...@lyra.org>.
[ yah, this is a bit late, along with my prior post... so sue me ]
On Wed, Apr 28, 2004 at 05:54:43PM -0700, Ben Reser wrote:
>...
> > A parser for the svn headers is definitively a different beast than a
> > C preprocessor.
>
> You can't possible parse header files without preprocessing them.
> Otherwise you'll not get the resulting true value of constants. Now I
> suppose you could run cpp on the files first and then parse the result...
Actually, I'm with Lele on this one. You can get practically 90% of the
SVN interface extracted with just a few regex. I demo'd this a long while
back with build/generator/extractor.py. It goofed on a few things, but
that was mostly due to non-standard formatting in the headers. After
fixing that up, there was one stray thought that svn_boolean_t was a
function, so extractor.py just punts on that.
Our header files are *very* regular. The simple reason is that we're a
single project. A full C preprocessor, or the complexity that is built
into SWIG, is there because it has to parse all kinds of headers. We have
the option to make our headers conform to our own parsing needs. That is
actually *very* handy, and can tremendously simplify the whole task.
> > Maybe, by the time I will be back on the matter, you will provide an
> > excellent and complete Pythonic world for svn, and we'll be happily
> > exchanging our experiences about which language better fits svn
> > problem domain. Till then, you are just promising.
>
> I didn't promise anything. I'll point out that we've had very few
> complaints about the Python bindings being incomplete. You seem to
> think they are not even up to simple tasks.
Heh. I've been using the Python bindings for years. Literally.
But that said: I doubt that Ben was bashing the Python bindings in that
way. Instead, I think each of you were just overreacting and should have
stopped to take a breath :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Python bindings
Posted by Lele Gaifax <le...@nautilus.homeip.net>.
>>>>> "Ben" == Ben Reser <be...@reser.org> writes:
Ben> But until you do write a Pyrex binding set there really isn't
Ben> anything to talk about further. Nobody on this list seems
Ben> interested in doing it.
Yes, and neither it seems a good place to talk about your baby, that's
so perfect. Most of the time, you most are attacking either the place
where one say something, or his capability to even discuss the matter.
that's all, sorry for the noise.
bye, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Python bindings
Posted by Ben Reser <be...@reser.org>.
On Thu, Apr 29, 2004 at 01:42:40AM +0200, Lele Gaifax wrote:
> Try use it. Even better, use it for the test suite. It will jump clear
> to your eyes that it has NOT. It's not up to even simple task.
That's odd. There are quite a few examples written for the Python.
blame was originally a feature prototyped as a python script ( I think
the example is still there). Our commit log hooks use the bindings.
viewcvs uses them. How about specifying what simple tasks it isn't up
to so we can fix it rather than hypothesizing about how it's not good
enough.
> Ah! Do swig need to parse C? And *still* has problem? How strange!
Well header files are C...
> A parser for the svn headers is definitively a different beast than a
> C preprocessor.
You can't possible parse header files without preprocessing them.
Otherwise you'll not get the resulting true value of constants. Now I
suppose you could run cpp on the files first and then parse the result...
> I won't debate with you my Python productivity compared to anything
> else. I bet that with a few regex it would be possible to extract
> what's needed to build the "direct level" layer. But I do not want to
> bother you with these advanced techs, stay focused on those $ and
> %....
You know I've dealt with a lot of Perl bashing over the years by Python
users. But this is downright ridiculous. It's totally uncalled for on
this list. Not to mention it doesn't answer the questions I raised.
> Maybe, by the time I will be back on the matter, you will provide an
> excellent and complete Pythonic world for svn, and we'll be happily
> exchanging our experiences about which language better fits svn
> problem domain. Till then, you are just promising.
I didn't promise anything. I'll point out that we've had very few
complaints about the Python bindings being incomplete. You seem to
think they are not even up to simple tasks.
All you've done is push a solution to a problem that you seem unwilling
to give concrete examples of. As I said in the past on IRC, you're
entitled to your opinion. You can even make this Pyrex bindings. More
power to you if you do.
But until you do write a Pyrex binding set there really isn't anything
to talk about further. Nobody on this list seems interested in doing
it.
Best of luck.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Python bindings
Posted by Lele Gaifax <le...@nautilus.homeip.net>.
>>>>> "Ben" == Ben Reser <be...@reser.org> writes:
Ben> Python already *HAS* the "one-to-one mirror" done. There may
Ben> be a few places here and there where we've added stuff that
Ben> Python hasn't kept up with, but for the most part that's
Ben> done.
Try use it. Even better, use it for the test suite. It will jump clear
to your eyes that it has NOT. It's not up to even simple task.
>> Believe me, I'd spend the needed time to write a little parser
>> for the very good svn headers to translate them into pyrex
>> interfaces (doc et all!!), rather than throwing away my time on
>> swig singularities.
Ben> So what you're saying is, you'll have to write a custom piece
Ben> of software in order to get Pyrex doing things for "free"?
Ben> Sounds to me like you're exagerating the ease at which you
Ben> can do things. SWIG has had a C pre processor for quite a
Ben> while and it *STILL* has problems parsing some C stuff.
Ah! Do swig need to parse C? And *still* has problem? How strange!
Ben> In the ind I think you're saying that you can write a C pre
Ben> processor faster than you can work with SWIG. Which just
Ben> seems flat out false to me.
A parser for the svn headers is definitively a different beast than a
C preprocessor. I won't debate with you my Python productivity
compared to anything else. I bet that with a few regex it would be
possible to extract what's needed to build the "direct level" layer.
But I do not want to bother you with these advanced techs, stay
focused on those $ and %....
>> I'm really out of time on other projects, so I cannot prove
>> this (now). I'm really sorry, but that's it.
Ben> All of which is moot because you don't have the time to do
Ben> something which is so easy and "almost-for-free". Humm...
Maybe, by the time I will be back on the matter, you will provide an
excellent and complete Pythonic world for svn, and we'll be happily
exchanging our experiences about which language better fits svn
problem domain. Till then, you are just promising.
ciao, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Python bindings
Posted by Ben Reser <be...@reser.org>.
On Thu, Apr 29, 2004 at 12:00:26AM +0200, Lele Gaifax wrote:
> No, what I tried to prove and, due my total lack of time to devote to
> it, failed, is that I'm /quiet/ sure that, with much less effort in
> time and resources, Pyrex could let cmpilato (and me :) to actually
> think at an OO layer, and maybe trying more alternatives and choose
> the better one, rather than struggling with the swig way, of writing
> awful wrapper code.
>
> Pyrex makes it almost trivial to get that "direct layer", that's
> all. It does not prevent it, as I tried to show in my initial,
> somewhat snobbed, message that started this thread. It surely frees
> lot of time that one could spend on other good things, I guess :)
I find this difficult to believe. From looking at the Pyrex
documentation it looks like a different way of doing things. But I
don't buy the argument that it is necessarily easier. The problems just
happen to be different.
> Sorry Ben, but no again. It's not a matter of being more powerful for
> Perl than for Python. Current Perl bindings are in better shape than
> Python's only for the effort spent on them by various people, not
> because of swig. That effort is not easily/mechanically reflectible on
> the other languages. When swig arrived, it was more thought for
> wrapping *old* libraries in a snap, rather than producing something
> with an high quality interface.
Huh? That's not what I said. In fact I'd say my statement agreed with
you. Which is exactly why I suggest you spend your time working on the
Python interfaces...
While the work to make the direct interface to the C API in Python is
helpful with the Perl version, the Perl OO interface is obviously not
helpful to the Python people. From what I'm seeing with Pyrex you wrap
the C API with Pyrex and then write Python code on top of that to give
it an OO interface (or Pyrex code which is really just Python turned
into C using the Python API). The end result seems to be the same for
about the same amount of work and probably would even look almost
identical (as far as the code to provide the OO interface). So I'm
entirely unclear on how it's easier to get an OO interface.
> Admittedly my Perl knowledge faded away, so cannot speak for that, but
> for Python I *do* think that the one-to-one mirror cmpilato wanna base
> the nicer OO on, that swig should/will provide, is far easily
> reachable with Pyrex, and the final product would be a full fledged
> first class python module, with documentation et all, rather than an
> intricated marshal-in/marshal-out dance.
Python already *HAS* the "one-to-one mirror" done. There may be a few
places here and there where we've added stuff that Python hasn't kept up
with, but for the most part that's done.
What needs to be done is the stuff you'd be doing outside of Pyrex. The
OO front end to the "one-to-one" mirror.
Additionally, how does Pyrex suddenly jump you from "an intricated
marshal-in/marshal-out dance" to a "first class python module, with
documentation et all [sic]." You make Pyrex sound like a silver bullet.
But wouldn't you still have to write the documentation? How does using
Pyrex get this done any easier? And what are the other things that
Pyrex is supposedly magically getting done for us that make a first
class module?
> So I do know the effort swig ate you all.
What? I don't think SWIG has really been all that difficult. Even
after looking at the Pyrex documentation I don't think it solves the
time consuming and difficult problems with wrapping our API... Namely
handling things like thunking callbacks, which as far as I can tell
Pyrex is still going to require that you do.
> Ben> It has some advantages.
>
> Like to ear ones :)
I've gone over them several times... I'm not doing it again. Not to
mention all the work that's already been done. You're advocating
essentially starting over from scratch...
> Ben> I think your time would be better spent working on writing
> Ben> the OO layer on top of SWIG.
>
> I really doubt. Been there, done that. Lots of things are missing, and
> are difficult/annoying/error-prone to get done with swig and almost
> there-for-free with a reasonable timespan spent on Pyrexing the svn
> libraries.
Like what is missing? I can think of a few things that haven't been
done in the SWIG Python bindings, mostly because they're just flat out
difficult to wrap. I don't see Pyrex as solving those difficulties.
You keep ignoring is that the SWIG stuff is pretty much done. You could
write the OO layer entirely in Python. After reading through the Pyrex
documentation, achieving the OO stuff looks to be the same amount of
effort assuming that the Python bindings are complete... The things
that aren't done with the SWIG bindings could be done by someone else,
and probably done in less time that it'd take you to do all the Pyrex
work from scratch.
> Believe me, I'd spend the needed time to write a little parser for the
> very good svn headers to translate them into pyrex interfaces (doc et
> all!!), rather than throwing away my time on swig singularities.
So what you're saying is, you'll have to write a custom piece of
software in order to get Pyrex doing things for "free"? Sounds to me
like you're exagerating the ease at which you can do things. SWIG has
had a C pre processor for quite a while and it *STILL* has problems
parsing some C stuff.
In the ind I think you're saying that you can write a C pre processor
faster than you can work with SWIG. Which just seems flat out false
to me.
> I'm really out of time on other projects, so I cannot prove this
> (now). I'm really sorry, but that's it.
All of which is moot because you don't have the time to do something
which is so easy and "almost-for-free". Humm...
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Python bindings
Posted by Lele Gaifax <le...@nautilus.homeip.net>.
>>>>> "Ben" == Ben Reser <be...@reser.org> writes:
Ben> However, cmpilato never rules out providing an OO interface.
Ben> He just states that he wants to have the more direct layer
Ben> available. In fact I think he even said he wanted to work an
Ben> a more Python like layer on top of the SWIG bindings when he
Ben> had time.
Ben> The real difference of opinion here is that you don't think a
Ben> nice Python-esque interface is possible with SWIG. Which I
Ben> doubt because the Perl SWIG bindings do have such a nice OO
Ben> interface and not because SWIG made them for us.
No, what I tried to prove and, due my total lack of time to devote to
it, failed, is that I'm /quiet/ sure that, with much less effort in
time and resources, Pyrex could let cmpilato (and me :) to actually
think at an OO layer, and maybe trying more alternatives and choose
the better one, rather than struggling with the swig way, of writing
awful wrapper code.
Pyrex makes it almost trivial to get that "direct layer", that's
all. It does not prevent it, as I tried to show in my initial,
somewhat snobbed, message that started this thread. It surely frees
lot of time that one could spend on other good things, I guess :)
I do acknowledge that everything is possible, with the right amount of
resources handy. But I can think of very few projects [as popular as
svn] that provide a *good* Python interface using swig.
Ben> You also seem to think SWIG is a bad choice for Python.
Ben> While at the same time think it's a better choice for Perl.
Ben> I have idea why. It's not really any nicer for Perl IMHO
Ben> than it is for Python. It might be able to do higher level
Ben> wrapping for us in Perl than Python, but we're not using it
Ben> anyway because I didn't like what SWIG generated...
Sorry Ben, but no again. It's not a matter of being more powerful for
Perl than for Python. Current Perl bindings are in better shape than
Python's only for the effort spent on them by various people, not
because of swig. That effort is not easily/mechanically reflectible on
the other languages. When swig arrived, it was more thought for
wrapping *old* libraries in a snap, rather than producing something
with an high quality interface.
Admittedly my Perl knowledge faded away, so cannot speak for that, but
for Python I *do* think that the one-to-one mirror cmpilato wanna base
the nicer OO on, that swig should/will provide, is far easily
reachable with Pyrex, and the final product would be a full fledged
first class python module, with documentation et all, rather than an
intricated marshal-in/marshal-out dance.
Ben> So don't get me wrong. I don't think SWIG is the end all
Ben> solution. But at the same time it's what we have been
Ben> working with for a long time.
Yeah, I'm **not** denigrating anyone, be that clear :-) Kudos to all
of you. As I said to you on IRC, I did spent lot-o-time in the past,
doing the matter, luckily very often focused on Python :)
So I do know the effort swig ate you all.
Ben> It has some advantages.
Like to ear ones :)
Ben> I think your time would be better spent working on writing
Ben> the OO layer on top of SWIG.
I really doubt. Been there, done that. Lots of things are missing, and
are difficult/annoying/error-prone to get done with swig and almost
there-for-free with a reasonable timespan spent on Pyrexing the svn
libraries. Believe me, I'd spend the needed time to write a little
parser for the very good svn headers to translate them into pyrex
interfaces (doc et all!!), rather than throwing away my time on swig
singularities.
I'm really out of time on other projects, so I cannot prove this
(now). I'm really sorry, but that's it.
Thank you Ben,
ciao, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Python bindings
Posted by "C. Michael Pilato" <cm...@collab.net>.
Ben Reser <be...@reser.org> writes:
> Now I think you're entirely misrepresenting the opinions given. You
> probably got this idea from reading cmpilato's replies. But I'm pretty
> sure that's not what he meant.
>
> He wants to provide a wrapping of the C APIs that is nearly identical to
> the C API in use. This ensures a full and complete wrapping of the
> APIs. There are other reasons to do this such as prototyping new
> feature expansions that we might want to add to the C based command line
> client in Python.
>
> However, cmpilato never rules out providing an OO interface. He just
> states that he wants to have the more direct layer available. In fact I
> think he even said he wanted to work an a more Python like layer on top
> of the SWIG bindings when he had time.
Thank you, Ben, for saying what I said better than I said what I said
when I said it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Python bindings
Posted by Ben Reser <be...@reser.org>.
On Wed, Apr 28, 2004 at 04:43:46PM +0200, Lele Gaifax wrote:
> Ben, I see that's almost impossible to push my arguments, since I feel
> that we do not share a common view on the "shape" the bindings could
> have. I'm more biased toward a high level approach rather than a mere
> one-to-one mapping between Python and C API, as I do not think that's
> what a Python developer like to use. Given that apparently Pyrex will
> give me the opportunity of easily building a OO layer with a clear,
> simpler and more direct connection to the C internals, that's where
> I'll spend my time on, whenever I'll get some.
Now I think you're entirely misrepresenting the opinions given. You
probably got this idea from reading cmpilato's replies. But I'm pretty
sure that's not what he meant.
He wants to provide a wrapping of the C APIs that is nearly identical to
the C API in use. This ensures a full and complete wrapping of the
APIs. There are other reasons to do this such as prototyping new
feature expansions that we might want to add to the C based command line
client in Python.
However, cmpilato never rules out providing an OO interface. He just
states that he wants to have the more direct layer available. In fact I
think he even said he wanted to work an a more Python like layer on top
of the SWIG bindings when he had time.
The real difference of opinion here is that you don't think a nice
Python-esque interface is possible with SWIG. Which I doubt because the
Perl SWIG bindings do have such a nice OO interface and not because SWIG
made them for us.
You also seem to think SWIG is a bad choice for Python. While at the
same time think it's a better choice for Perl. I have idea why. It's
not really any nicer for Perl IMHO than it is for Python. It might be
able to do higher level wrapping for us in Perl than Python, but we're
not using it anyway because I didn't like what SWIG generated...
So don't get me wrong. I don't think SWIG is the end all solution. But
at the same time it's what we have been working with for a long time.
It has some advantages. I think your time would be better spent working
on writing the OO layer on top of SWIG. I think I said all this on IRC
the last time we talked about this. So this is probably just rehashing
what I've already said.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Python bindings
Posted by Lele Gaifax <le...@nautilus.homeip.net>.
>>>>> "Ben" == Ben Reser <be...@reser.org> writes:
Ben> What you're not accounting for is that while specific
Ben> implementation details may differ many of the problems
Ben> encountered by the Python bindings are identical to the
Ben> problems encountered by the Perl bindings.
What I'm stating is that Perl and Python are different enough to
warrant a different implementation of the bindings. I still think
that the benefit of using swig with Python is very debatable, while I
know that it's a must for practical reasons in the Perl world.
Ben> I've often found it useful to look at the Python bindings to
Ben> figure out how they dealt with a problem.
You are lucky: I see me doing the exact opposite... and Perl's API is
somewhat more tricky than Python's...
Ben> In many cases what we have to do implemented in psuedo code
Ben> is identical, differing only by the calls to different
Ben> functions in APIs provided by the languages we're using.
Ben, I see that's almost impossible to push my arguments, since I feel
that we do not share a common view on the "shape" the bindings could
have. I'm more biased toward a high level approach rather than a mere
one-to-one mapping between Python and C API, as I do not think that's
what a Python developer like to use. Given that apparently Pyrex will
give me the opportunity of easily building a OO layer with a clear,
simpler and more direct connection to the C internals, that's where
I'll spend my time on, whenever I'll get some.
ciao, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Python bindings
Posted by Ben Reser <be...@reser.org>.
On Tue, Apr 20, 2004 at 07:40:01PM +0200, Lele Gaifax wrote:
> But even then, saying that there is an effective code sharing between
> the bindings is a bit optimistic: the hardest part /introduced/ by
> SWIG is that you need go and implement a wrapper for each object / for
> each language. Yes, the /declarations/ are in common, but the hard
> work of dealing with arguments-transformer-function coupled with
> this-and-that function signature is a pita.
Sure, but every language is a little different. What you're not
accounting for is that while specific implementation details may differ
many of the problems encountered by the Python bindings are identical to
the problems encountered by the Perl bindings.
I've often found it useful to look at the Python bindings to figure out
how they dealt with a problem. In many cases what we have to do
implemented in psuedo code is identical, differing only by the calls to
different functions in APIs provided by the languages we're using.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Python bindings
Posted by Lele Gaifax <le...@nautilus.homeip.net>.
>>>>> "Daniel" == Daniel L Rall <dl...@apache.org> writes:
Daniel> C. Michael Pilato wrote: ...
>> I think the fact that would benefit only the Python side of
>> things is non-negligible downside.
Daniel> ...
Daniel> This is an important point. What about all the other
Daniel> languages which SWIG supports? Sharing the core of the
Daniel> bindings implementation across languages is powerful
Daniel> reuse.
As said, I second that. But when it comes to effectively weighting
the hassle/benefit ratio, I think that other more specific ways of
laying down the bindings would make them a) more powerfull and b)
maintainable.
But even then, saying that there is an effective code sharing between
the bindings is a bit optimistic: the hardest part /introduced/ by
SWIG is that you need go and implement a wrapper for each object / for
each language. Yes, the /declarations/ are in common, but the hard
work of dealing with arguments-transformer-function coupled with
this-and-that function signature is a pita.
ciao, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Python bindings
Posted by "Daniel L. Rall" <dl...@apache.org>.
C. Michael Pilato wrote:
...
> I think the fact that would benefit only the Python side of things is
> non-negligible downside.
...
This is an important point. What about all the other languages which SWIG
supports? Sharing the core of the bindings implementation across languages is
powerful reuse.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Python bindings
Posted by "C. Michael Pilato" <cm...@collab.net>.
Lele Gaifax <le...@nautilus.homeip.net> writes:
> While it's clear that this would benefit only the Python side of the
> bindings, I think that the new layer would be more powerful and at the
> same time much more manageable.
>
> What do you think?
I think the fact that would benefit only the Python side of things is
non-negligible downside. I also am not impressed with claims that
Python bindings that behave more Pythonic is actually in and of itself
a good thing. I rather prefer the system we have today, where the
'libsvn' module exposes our public APIs in a form familiar to
programmers of those APIs as used in C or C++. And then we have the
'svn' module, which (when I get some free time) will not merely wrap
libsvn, but will do so by creating more Pythonic objects (classes,
etc.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Python bindings
Posted by Barry Scott <ba...@barrys-emacs.org>.
On Apr 30, 2004, at 09:49, Lele Gaifax wrote:
>>>>>> "Barry" == Barry Scott <ba...@barrys-emacs.org> writes:
>
> Barry> Check out pysvn which is an OO Python interface to svn
> Barry> client functionality.
>
> Thanx Barry, I gave a look at that, but I really dislike the
> approach. Even if it's a good work, compared to actual bindings, it's
> being C++ based does not appeal me.
Pardon? Why do you care how I achieved the goal you wish met?
Did I misunderstand what you want to do?
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Python bindings
Posted by Lele Gaifax <le...@nautilus.homeip.net>.
>>>>> "Barry" == Barry Scott <ba...@barrys-emacs.org> writes:
Barry> Check out pysvn which is an OO Python interface to svn
Barry> client functionality.
Thanx Barry, I gave a look at that, but I really dislike the
approach. Even if it's a good work, compared to actual bindings, it's
being C++ based does not appeal me.
Bye, lele.
--
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
email: lele@seldati.it | -- Fortunato Depero, 1929.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Python bindings
Posted by Barry Scott <ba...@barrys-emacs.org>.
On Apr 18, 2004, at 18:32, Lele Gaifax wrote:
> Hi all,
>
> I spent some time studying Pyrex_, and wonder if anybody considered it
> for a next-generation Python bindings implementation.
Check out pysvn which is an OO Python interface to svn client
functionality.
Its documented, supported and shipping. I have a replacement for the svn
command as an example and the WorkBench GUI as a large scale user of
pysvn.
The home page is http://pysvn.tigris.org
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org