begging for pyme name change

Daniel Kahn Gillmor dkg at fifthhorseman.net
Thu Oct 20 17:45:24 CEST 2016


On Thu 2016-10-20 03:54:12 -0400, Justus Winter wrote:
> Now comes the tricky part.  Pyme2's interface was deemed too unpythonic,
> so I created a new interface on top of the old one that was quite
> faithful to the C API.  In particular, the 'op_' prefix was perceived as
> ugly.  This is how the pyme3 shim looks:
>
>     with pyme.Context(armor=True) as c:
>         ciphertext, _, _ = c.encrypt("Hallo Leute\n".encode(),
>                                      recipients=keys,
>                                      sign=False,
>                                      always_trust=True)
>
> I don't see how we could make that compatible with pygpgme's .encrypt.

I agree that these two context.encrypt() functions are incompatible on
their face.

However, it might be possible to inspect the types and number of the
arguments and make an educated guess.  something like:

   If the function receives exactly 4 arguments of type <sequence of
   gpgme.Key, integer, BytesIO, BytesIO> and none of them are kwargs,
   then follow the python-gpgme semantics (and maybe emit a warning
   encouraging transition to the preferred semantics?)

What do you think?  Are there other incompatibilities like this?

> We could ship a 'gpgme' Python module that provides a pygpgme-compatible
> API on top of pyme, and keep our 'pyme' Python module where we can
> introduce new features.  But maintaining two APIs and shipping two
> Python modules in order to take over the name does not make sense.  Even
> less so since we still couldn't use the 'gpgme' Python module for the
> interface that we want to develop and promote for new users.

I agree that this dual-module approach isn't a healthy or useful one.

I still think that taking over the python module name "gpgme" would be a
good thing, though.

This is might end up being frustrating bookkeeping work.  But it's work
that could help simplify things for future developers who are interested
in using the GnuPG suite in python, which would be a serious win.

It's certainly frustrating that there's no clear way to make a clean api
break in a given python module namespace.  It makes maintenance and
ongoing support difficult.

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


More information about the Gnupg-devel mailing list