python bindings for gpgme

[Bernhard Reiter]

Hi Justus,

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. 

I appreciate the effort to improve the python bindings 
and have official ones, too. My questions about the decision
are asked in order to help GnuPG to get better python bindings.


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

> > does not mean it is necessarily good or elegant to create good
> > binding for one language.
>
> We did not create the binding, it was already there.

I know (you have probably seen my code in there).
Still it may not be a good one.

[..]

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

> 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.
Also it will be the quality of the defects, not just the number.
Difficulties of writing correct code are always correlated in a linar way.
(Anyway you all know this, I guess.)

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

> > 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.
We should look at the API ideas of pygpgme, I guess.


> > A secondary concern is how it is implemented.
>
> I have some experience with creating bindings for Python, and I'm
> familiar with the available FFI solutions.  SWIG may be a more classic
> solution, but I don't see any problem with the method.

As we agree on the first concern, let us concentrate on that.

> > What will be the status of the gpgme/lang/python binding when gpgme will
> > be released? experimental? beta?
>
> Why would we release something experimental?

(To make it available and to mark it as something that still will change.)
Or are you asking this Werner who "released" the experimental WKD with 
Gnupg 2.1.12? >:)

> > Once people start relying on it, it will be harder to change the API
> > itself.
>
> People are already relying on it.  pygpgme isn't the only binding that
> already existed. 

It had no python3 port, so I venture that no Free Software initiatives
rely on the python3-gpgme (as in master) currently.

> Existing projects using pyme should have no trouble switching over.

I have no usage stats for pygpgme or pyme. pygpgme could also be a large
group. API changes can be expected when switching the library or the version 
of python. However usually GnuPG is very conservative with its APIs.

> > > Here is what a decrypting filter looks like with the current bindings:
> >
> > (This is only a simple example, so its value is limited.
>
> Yeah, if you have a better example maybe it is a good idea to write it
> down here so that we can discuss it.  I created that simple example
> just to see how simple one can implement decryption with the current
> bindings.  That was the point.

The question was which libary suggest the better API, I merely pointed out 
that your simple example does not help much answering the question.

> > I think that the "op_" part looks ugly.)
>
> Which we can drop, breaking all pyme applications in the process.  

no real one (see above). .. and breaking the pygpgme application
at the same time. 

> We  could, however, add a 'decrypt' operation to the Context class *in
> Python* that combines decryption and fetching all relevant results.

Overall I have not yet seen a deeper analysis of the APIs suggested 
by pygpgme and pyme. The API of the upcoming python3-gpgme was choosen 
without the potential lessons of such a comparison. I am not in a position to 
provide such an analysis on short notice and we are short on time anyway.
Maybe somebody can. Otherwise let us just hope for the best.

Best Regards,
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/3fc1ad64/attachment.sig>