begging for pyme name change

Daniel Kahn Gillmor dkg at
Mon Oct 17 21:40:08 CEST 2016

On Mon 2016-10-17 14:31:38 -0400, Vinay Sajip wrote:

> It appears to be all about Python bindings to GPGME. However, my
> project, python-gnupg, deliberately avoids binding to any C-level
> library and instead provides a wrapper around the gpg executable.

I agree with this, but…

> The bindings-to-C and wrapper-over-gpg models are both useful in
> different contexts, and should continue to co-exist as long as
> possible.

… i'm not sure i'd reach this conclusion in the abstract.

In particular, it'd be nice to see a single clear way to use gpg in
python, so that people using python don't have to choose between one
mechanism or another.  what if they want functionality that's only
available in one mechanism, and then they *also* want functionality
that's only available in the other mechanism?  Python is supposed to
make those sorts of choices easy, and maintaining both approaches sounds
troubling for the downstreams.

This is something for the upstream GnuPG team to wrestle with too -- how
do we make it easy for people to use GnuPG in a reliable way from other
programs?  It hasn't been as easy as it should be.

> Of course the python-gpgme name is also taken (by James Henstridge's
> package - I'm not sure how maintained that is, I couldn't see any
> releases more recent than 2012 and nothing in the source repository
> newer than 2013). However, it would make more sense to see if

i think you were about to suggest asking him for that name -- i agree,
and we've already reached out to him on a different branch of this
discussion.  Thanks for the suggestion!

And, thanks for your ongoing work on python-gnupg.  It's very much

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: </pipermail/attachments/20161017/1970aaa9/attachment.sig>

More information about the Gnupg-devel mailing list