On Thu 2019-08-22 19:37:34 +0000, Rollins, Jameson wrote:
> Ug, this naming issue is unfortunate.  I don't really like "notmuch3" as
> a reference to python 3, honestly.

how about notmuch3000? :P

> What about making these new bindings only for python3, and the old ones
> relegating to python2, and then just using the same name?  Is that too
> confusing?  Do we need to maintain both concurrently?

I don't like the idea of the same-named module with radically different
syntax and semantics.  That'd be fine if python modules had a way to
indicate backward incompatibility, but they don't :/ Just naming the new
module "notmuch" when existing code expects a certain API will result in
a real mess of downstream breakage.

The other possibility would be to implement the old "notmuch" API on top
of the new one with explicitly logged deprecations. But iirc, the
semantics and object lifecycle/ownership issues are subtly different
enough that this would be a non-trivial project.  I'd be happy to be
wrong though, perhaps someone closer to the systems (someone actively
using the current python bindings on an ongoing project?) could look
more closely?

here's what i see as plausible/possible names for the new module if we
can't replicate the old API on top of it:

 * notdb
 * notmuch2
 * notmuch3
 * notmuch_ng (ng == "next generation")
 * not2much
 * notmuchmail
 * notmuch3000
 * notmuch_cffi
 * pynotmuch

     --dkg