python bindings for gpgme

[Justus Winter]

Hi Bernhard,

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.

Agreed.

> 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.

> 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.

> 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.

> So far I haven't done a comparison between pygpgme and pyme.

Let's compare encryption then:

pyme: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=lang/python/tests/t-encrypt.py;h=24869fcd15e19a4cef2e5144570d9a5d37586e58;hb=HEAD
pygpgme: http://bazaar.launchpad.net/~jamesh/pygpgme/trunk/view/head:/tests/test_encrypt_decrypt.py#L99

I don't see much of a difference really.

> 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.:

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=lang/python/pyme/core.py;h=cc262c95aba3abc9fb7986af62e9b579b8229723;hb=HEAD#l529

> 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 ;)

Here is what a decrypting filter looks like with the current bindings:

~~~ snip ~~~
import sys
from pyme import core
core.check_version()
core.Context().op_decrypt(core.Data(file=sys.stdin), core.Data(file=sys.stdout))
~~~ snap ~~~

And I plan to bring it down to:

~~~ snip ~~~
import sys
from pyme import core
core.Context().op_decrypt(sys.stdin, sys.stdout)
~~~ snap ~~~

Also, I'm thinking about offering an 'open' function that offers
transparent encryption/decryption, similar how there is 'codecs.open'
offering transparent encoding/decoding.

Cheers,
Justus