python bindings for libassuan

[Daniel Kahn Gillmor]

On Fri 2015-05-08 09:29:04 -0400, Ben McGinnes wrote:

> Excellent, I'll definitely take a peek at that.  Did you opt for
> ctypes, the plain Python C-API or one of the other solutions?

The plain Python C-API.  I tend to find ctypes mappings not very
pythonic, especially for libraries with interesting/complex C workflows
like libassuan.

For example, ctypes for the assuan_transact(), with its C function
pointers and void* would be deeply weird in python (or at least i
couldn't figure out how to make that seem sensible).  Instead, I made a
python object assuan.context, which has python methods which get called
during a transaction.

>> I've targeted Python 3, and haven't bothered to try to make it work on
>> Python 2.x.
>
> As long as it doesn't get too complex you can probably get Python 2.7
> covered by including the UTF-8 encoding near the top of each file and
> including "from __future__ import unicode_literals".

Ah, i'm less concerned about the pure-python parts of it than the C-API,
which i think might have changed incompatibly between 2 and 3 (so i
don't want to uglify-up the C code with a ton of nasty #ifdefs -- but if
someone sends clean-ish patches to make it compile correctly against
python2, though, i would definitely accept them.

> LGPL 2.1+ is good, we want people to switch to things like this or
> GPGME.  If it is not provided with a permissive enough license then
> people will continue to use python-gnupg with its subprocess calls to
> the gpg binary.  Do you really want that?

Well, for gpg, it's all doing subprocess calls to the gpg binary
somehow, whether that's managed through gpgme or in python directly :/

Please let me know what you think after taking a look at it!  Hopefully
gnupg-devel is an OK place for this discussion for now.

         --dkg