begging for pyme name change
uri at mit.edu
Tue Oct 18 17:04:25 CEST 2016
One quick point: as far as I know, the highest "brand recognition" today is gpg, probably followed by PGP (at least among those who remember :)), gnupg being a distant third.
And I've been with PGP development since its inception.
Sent from my iPad
> On Oct 17, 2016, at 12:47, Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
> [ adding Vinay Sajip to this e-mail thread, so he knows this is under
> discussion; Vinay, if you haven't been following this discussion about
> the various python/gnupg namespace issues, you can see the start of
> the discussion over at
> https://lists.gnupg.org/pipermail/gnupg-devel/2016-October/031810.html ]
>> On Mon 2016-10-17 03:51:27 -0400, Bernhard Reiter wrote:
>> https://bitbucket.org/vinay.sajip/gnupg is not the official python GnuPG API
>> and "gnupg" is **our** namespace so to say. (Still any Free Software
>> contribution is nice, so it is cool that this module was written and
>> published. On the other hand, if we try to raise adoption for GnuPG, we all
>> have a strong interest that there is recognition about what is more or less
>> maintained.) IMO "python-gnupg" is the best name for this.
> I hear you, but let's be clear that Vinay Sajip was maintaining this
> wrapper long before the GnuPG upstream team decided to offer any sort of
> python functionality at all.
> I think the fact that upstream is now aiming to take responsibility for
> a python binding to GnuPG is great; but we can't ignore the fact that
> this other project was out there filling this need long before upstream
> was. And this other project has an existing userbase that would be good
> to reach out to, rather than to ignore.
>> If there are conflicts any distribution could solve them by version numbers
>> when in doubt. Maybe debian would use package names like
>> To show that the there was an incompatible API change.
>> My guiding principle is: what name would developers expect when looking
>> for the GnuPG API?
> right, and the lack of declared upstream support has left this vacuum
> where the existing multiplicity of projects are all (confusingly)
> available. It's not clear to me how to break this logjam, even if we
> manage to get all parties in agreement that there should be a single
> preferred pythonic interface to GnuPG.
>> The brand recognition is specifically highest about "gnupg" not "gpg".
> I have no idea whether this is true or not. How are you measuring it?
>> So the connection is: If you want GnuPG's quality for crypto from python,
>> use its python module.
> I agree that this phrasing is probably better than the term "binding",
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
More information about the Gnupg-devel