python bindings for gpgme

[Bernhard Reiter]

Hi Justus,

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

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:
>
> pyme:
> http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=lang/python/te
>sts/t-encrypt.py;h=24869fcd15e19a4cef2e5144570d9a5d37586e58;hb=HEAD pygpgme:
> http://bazaar.launchpad.net/~jamesh/pygpgme/trunk/view/head:/tests/test_enc
>rypt_decrypt.py#L99
>
> 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.:
>
> 
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=lang/python/pyme/core.py;h=cc262c95aba3abc9fb7986af62e9b579b8229723;hb=HEAD#l529

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

Best,
Bernhard

-- 
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...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20160601/009e9fac/attachment.sig>