python bindings for gpgme

[Justus Winter]

Hello Bernhard,

Quoting Bernhard Reiter (2016-06-01 17:54:43)
> Am Mittwoch, 1. Juni 2016 16:15:04 schrieb Justus Winter:
> > > so we probably should evaluate this.
> >
> > I just did, and as Werner noted, we are very well beyond the
> > evaluation phase.
> 
> your evaluation looks a bit biased because you are defending
> what you have currently implemented.

What else would I be defending?

> 
> > SWIG requires *only* language-specific code.  In case you are curious,
> > it is here:
> > 
> http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=lang/python/gpgme.i;hb=HEAD
> 
> I still don't see that defying my argument that SWIG as an additional layer 
> creates some overhead (learning python's c api and swig).

It defies your argument that using SWIG only pays off if you create
bindings for more than one language, which can only be the case if
there is a language-independend part to it, which there isn't.

> > > 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).
> >
> > I disagree.
> >
> > With SWIG, you write functions translating c types to python types and
> > back.  Any function provided by the c library is then automagically
> > wrapped, with the data being converted by the functions you wrote
> > *once*.  Add a new function to gpgme, and you likely don't need to do
> > anything in pyme.
> 
> When debugging you need to fully understand the resulting c-code
> and it was more complicated with SWIG (last time I've tried).
> 
> > With pygpgme, you write code translating the types forth and back
> > *explicitly for every function you want to make available to python*.
> > It is a huge overhead, and likely a source of many errors as that code
> > is likely copied over and over again, without being properly
> > understood.
> 
> I haven't checked how it is implemented in pygpgme, there will be typical C 
> methods to avoid too much code duplication.

One of such typical methods is code generation, which is exactly what
SWIG does.  In fact, pyme and pygpgme are very similar, they employ a
compiled module at the core, but pyme uses SWIG to generate large
parts of that code.

> > Let's look at the sizes:
> >
> > % sloccount pygpgme/src
> > [...]
> > 3037    src             ansic=3037
> > % sloccount lang/python/helpers.* lang/python/gpgme.i lang/python/pyme
> > 544     top_dir         ansic=544
> > 497     pyme            python=497
> >
> > Based on that I gather that there must be three to six times as many
> > bugs in pygpgme.
> 
> If it is mostly duplicated code, your estimation does not hold.

I doubt that.  In fact, I believe that copying code around increases
the chance of errors, and that it leads to cargo-cult-style
programming.  It also makes fixing these bugs hard.

> > > 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.
> >
> > So let's combine these operations in pymes python shim.
> 
> Before the release? Or do we have two ways to achieve the same thing then?

I'm thinking of providing joined operations,
op_decrypt_verify+op_decrypt_result+op_verify_result =>
decrypt_verify.  So there would be a second set of operations.

> > > My main concern is the python API.
> >
> > I understand that, and I believe that providing a more pythonic api is
> > easier with pyme, for reasons I repeatedly stated.
> 
> If it is done with SWIG or later with CFFI, I don't care.

Ok.

> We should look at the API ideas of pygpgme, I guess.

What ideas?  I'm tired of "make it more pythonic" with noone having a
clear idea what that actually means.  I fear that it means something
different for everyone.  So until someone here actually provides a
constructive critique of the current pyme API, I'm going to sand-off
the edges that would annoy me the most.

For example, one can now just use file objects everywhere a
gpgme_data_t object is expected (in most cases):

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=lang/python/tests/t-idiomatic.py;hb=HEAD#l28

I plan to extend this to every object implementing the buffer
interface.  I also want to provide the compound operations, and work a
little on the documentation.


Cheers,
Justus