python bindings for gpgme
bernhard at intevation.de
Wed Jun 1 14:53:38 CEST 2016
Am Mittwoch, 1. Juni 2016 12:02:57 schrieb Justus Winter:
> Quoting Bernhard Reiter (2016-05-31 21:23:48)
> > In my experience what counts most for python developers is that the
> > bindings are very pythonic.
so we probably should evaluate this.
> > In my limited experience the SWIG layer makes this harder to do.
> I don't see why. SWIG creates a really thin layer, and the resulting
> interface is a very faithful image of the c api. Note that the same
> is true for every FFI solution.
You can probably implement a speficic API with all four solutions
that have been mentioned (swig, cffi, cython and manual c-code).
But, as Ben also noted SWIG is old style and the design decision
of SWIG (AFAIR) was to generalize the interface to generate bindings for
several languages at once.
> > Also the additional abstraction really pays out if you use SWIG to
> > create binding for a number of languages.
> Not true. SWIG requires target language-specific code.
That SWIG requires some language-specific code does not mean
it is necessarily good or elegant to create good binding for one language.
The design goal is to abstract and so SWIG aims towards that goal,
making it harded to use SWIG for python only. Of course if you want to support
ruby, python and some more at once, this extra effort may pay out.
> > Otherwise it is just one more abstraction layer to learn when you
> > want to debug or extend things.
> I disagree. It is quite the opposite really, with pyme/SWIG we get
> most enhancements to GPGME for free, whereas in pygpgme it requires a
> lot of c code talking to Python's c api.
My argument is: First I have to understand python's c api with SWIG I have to
understand python's c api and SWIG (and its generated code).
> > So far I haven't done a comparison between pygpgme and pyme.
> Let's compare encryption then:
> I don't see much of a difference really.
Comparing the operation and the results, pygpgme combination
into one call seems more pythonic to me. Over time this will add up to a lot
of more code.
> > From my point of view the most pythonic one should be used.
> And here is the thing. While pygpgme is implemented purely in c, and
> any attempt of making it more pythonic must also be done in c, pyme is
> using SWIG for the FFI, and layers a shim written in Python on top.
> This is the place one augments or extends the api to make it more
> pythonic, e.g.:
My main concern is the python API.
A secondary concern is how it is implemented.
You can see that python people move off SWIG to stuff like CFFI (which Ben
reported about last May). pygpgme is closer to something like CFFI, one layer
less indirection (though more c-code).
> > pygpgme is already available for python3 for a few years longer than
> > pyme, I believe.
> I must admit I didn't compare pygpgme and pyme before, mostly because
> I wasn't around when the initial effort started, but if I should
> choose now, I'd chose pyme as a starting point again. Having said
> that, I agree that making it a little more pythonic is important, as
> Python is the cheese to catch developers these days. And we will do
> just that ;)
What will be the status of the gpgme/lang/python binding when gpgme will be
released? experimental? beta?
Once people start relying on it, it will be harder to change the API itself.
> Here is what a decrypting filter looks like with the current bindings:
(This is only a simple example, so its value is limited. I think that
the "op_" part looks ugly.)
www.intevation.de/~bernhard +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 473 bytes
Desc: This is a digitally signed message part.
More information about the Gnupg-devel