python bindings for libassuan
ben at adversary.org
Sat May 9 04:27:26 CEST 2015
On 9/05/2015 5:25 am, Daniel Kahn Gillmor wrote:
> On Fri 2015-05-08 14:57:48 -0400, Ben McGinnes wrote:
>> I strongly suspect that wiping the slate clean and writing a "proper"
>> Python driven API, as Werner suggested, would've had to be done
>> anyway. Doing all that as C-API modules, however, is a ridiculously
>> mammoth undertaking, so in that case something which lends itself a
>> little more towards a reasonable development timeframe is far more
> As you've seen, the approach i took was to make a plausible stab at a
> python mapping to the underlying C library via the C-API, and then write
> a bit more sensible/pythonic type stuff in python around that core.
Right, which is the sort of thing I'll look to for pointers when I
start crafting the other thing. Might also have to try to recall
where I left that copy of K&R's C book.
>> The two options currently under consideration are Cython and CFFI,
>> even though neither are part of the standard library.
> I don't know anytihng about these approaches, i'm afraid i'm a bit of a
> python newbie.
Whereas it's the one language I'm most comfortable with. A result of
it being the language of choice at my first tech employer (an ISP).
Anyway, CFFI is what the Python Cryptography project uses, though
they're also moving towards using PyCrypto for their backend (which in
turn relies on OpenSSL and a whole bunch of custom contributed C
modules for Python). If I take the CFFI route then there's some good
examples in their code:
Cython, on the other hand, takes a rather different approach, but it
very closely resembles Python code and can be used to generate C
source code. So it's effectively possible to write something that's
99% Python which will produce C source code that will compile into a
CPython module and once the source is written it will happily compile
on multiple platforms and for multiple Python implementations and
versions. I wouldn't write a kernel with it (or implement a
cryptosystem from scratch), but pretty much everything else is up for
Both have significant advantages depending on the intended outcome,
but I think CFFI might be a little easier both to code and to manage.
Depending on whether or not using it to load libgpgme.[so|dylib|dll]
or libassuan.[so|dylib|dll] is enough to achieve the end goal. If not
then Cython may step up to the plate to take care of building a
CPython module with the relevant libs, but everything I've seen so far
indicates CFFI can do it all (including callbacks). I think I might
have to give both a spin before deciding, though.
> I've looked at SWIG, and agree that the interfaces it produces by
> default look scary and non-pythonic for libraries like libassuan.
Yeah, it's only as entrenched as it is because for a long time it was
the only option at all that didn't involve coding Python modules in C,
like the core of CPython is. Well, there was Boost too, but to say
it's painful to configure is an understatement.
>> I also have your first patch for you if there's somewhere I can push
>> it to. It's not much, just a more pythonic way of specifying the
>> homedir in assuan/gnupg.py. The relevant bits are attached.
> Thanks, applied and pushed.
> If you send your patches as produced via "git format-patch" (or even
> easier, sent via "git send-email") then they're easier for me to apply
> directly, rather than sending the log and the patch as separate
Ah-ha, more git voodoo! It can be a peculiar little thing at times,
but it works. Added that one to my cheat sheet, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 630 bytes
Desc: OpenPGP digital signature
More information about the Gnupg-devel