python bindings for libassuan
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Fri May 8 16:56:32 CEST 2015
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
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.
More information about the Gnupg-devel