Barry Scott wrote:
>> PyCXX instead of SWIG? I don't see any advantages to doing that. The
>> main advantage that Boost::Python and (presumably) PyCXX have over
>> SWIG is that they let you easily access Python features from C++, so
>> you can build cool hybrid C++/Python apps. But in this case, you're
>> not implementing parts of the library in python, just exposing it
>> all to python. Beyond that, using PyCXX would give you two potential
> PyCXX allows me to use a very pythonic API. For example I have a
> revision object that allows me to:
> rev = pysvn.revision()
> rev.kind_name = "head"
> And a ls that takes keywords and returns a list of dicts for the
> result with times converted to python time.
> client = pysvn.client()
> all_files = client.ls( url, recurse=true, revision=rev )
> for file in all_files:
> print file['name']
As you say in your other message, this can all be done with typemaps.
> I can also support threading by releasing the python interpreter lock
> around the svn calls.
SWIG does this by default.
> How would SWIG support all the callbacks?
Does Svncpp even use callbacks? I'd expect it to use virtual member
functions instead. Swig does supports overriding virtual members functions
in python (http://www.swig.org/Doc1.3/Python.html#n32). If SvnCpp does use
callbacks, they can be supported with typemaps.
> I can isolate the Python world from crashing from bad param passing.
You could write additional parameter validation code with swig, too.
Anyway, considering that you are a PyCXX developer, and are just beginning
to get acquanted with SWIG's features, I'll take back what I said about
PyCXX not having any advantages over SWIG in this case. You should go with
what you know.
>> 1) The SvnCpp bindings wouldn't be able to interoperate with the
>> Subversion C bindings.
> Why would I need this interop? I don't understand why it matters.
I listed this as a *potential* disadvantage because, I don't know enough
about SvnCpp to know if it actually does matter. But AFAICT, SvnCpp only
wraps a small portion of the Subversion API, so it is concievable that a
user might want to call a subversion API with SvnCpp data in order to access
some feature that hadn't been wrapped.
>> 2) The SvnCpp bindings wouldn't be available to Perl, Java, Ruby,
>> PHP, etc, etc users.
> My goal is a Python API and I'm not convinced that SWIG can make a
> good python API. I know that PyCXX can. SWIG may be good enough to
> the other languages.
I'll stop trying to convince you, but as far as I know SWIG does not prevent
you from using any Python features.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sun Oct 19 20:31:24 2003